-
Notifications
You must be signed in to change notification settings - Fork 8
프론트엔드‐스타일링 상태관리 방법 선택 및 이유
sass, scss, css module 등을 이용하여 개발한다면 빌드 결과물이 css로 나옵니다. 이는 css-in-js 라이브러리를 사용했을 때보다 런타임 오버헤드가 적지만 상태에 따른 동적 스타일링이 어렵다는 단점이 있습니다.
styled-component, emotion 과 같은 css-in-js 라이브러리를 사용하여 빌드할 시 스타일 관련 코드가 css 파일이 아닌 자바스크립트 코드로 생성됩니다. 이는 자바스크립트 코드로 실행되기에 런타임 오버헤드가 있기도 하고 해당 js 파일이 html element 에 적용되는 방법에 대한 로직이 들어있는 번들링을 추가로 로드해야하기에 사용자가 로드해야할 파일 크기가 증가한다는 단점이 있습니다.
우선 프로젝트 규모가 크지 않고 기획상 복잡한 스타일이 추가되지 않기에 오버헤드가 적을 것으로 추측하였고, 이러한 오버헤드가 사용자에게 미치는 영향의 부정적인 측면보다 동적 스타일링 및 코드의 가독성으로 인한 DX(Developer eXperience) 향상의 이점이 더욱 많다고 판단하여 css-in-js 를 사용하게 되었습니다.
우선 팀원이 styled-component 라이브러리 사용에 더욱 익숙하여 emotion 이 아닌 styled-component 사용을 선택했습니다. 그 외에도 emotion 의 높은 자유도의 스타일링 방식으로 인해 emotion 컨벤션 통일에 대한 추가 논의가 필요하기에 스타일 방식이 고정된 styled-component 방식을 채택했습니다.
추후 필요 시 도입 예정
React Query를 이용하여 불필요한 서버 데이터 요청을 최소화할 수 있습니다. 만약 특정 시간 동안 서버의 데이터가 변하지 않거나 변경된 데이터를 가져올 필요가 없는 경우 서버로 데이터 요청을 하지 않고, 이전에 받았던 데이터를 활용하여 UI 구성을 할 수 있습니다. 그로 인해 사용자는 서버의 데이터 응답을 기다려야 하는 수고를 덜 수 있고 사용자 경험(UX)을 향상할 수 있습니다.
그 외에도 이전에 요청했던 데이터를 다시 요청하는 경우 React Query를 이용하여 서버의 응답이 올 때까지 로딩 화면을 보여주는 방식이 아닌 이전 데이터를 사용자에게 보여주다가 만약 새로운 데이터를 응답받으면 그 새로운 데이터를 기반으로 리렌더링하여 UI를 보여주어 UX 향상을 기대할 수 있습니다.