스타일링 상태관리 방법 선택 및 이유
- 컴포넌트의 상태, props, 혹은 기타 변수값에 따라 동적으로 변화하는 스타일링을 구현하기에 용이하다고 판단했습니다.
- 특히 대시보드 등 하나의 화면 안에서 다양한 기능을 제공해야 하는 크루루의 서비스 특성을 고려할 때, 신속하면서도 간편한 구현을 가능하게 해줄 방법이라 생각했습니다.
- 지난 2차 스프린트 중 해커톤을 진행하던 과정에서, PandaCSS의 기술적 이점에 비해 아래의 단점들이 더 부각되는 상황을 마주했습니다.
- 부족한 공식 문서 지원 : Webpack 기반 React 프로젝트에 이 라이브러리를 연결하는 데에 필요한 내용이 잘 명시되어 있지 않았습니다. 이에 따라 초기 세팅 과정에서 잦은 트러블슈팅 상황을 겪었습니다.
- 디자인 토큰 지원 문제 : 공식적으로는 디자인 토큰 기능을 제공한다고 되어 있으나, 실제로는 공식 문서 내용대로 적용했음에도 코드 레벨에서부터 잦은 에러가 발생했습니다.
- 빈약한 사용자 커뮤니티 : 상당히 최신의 라이브러리인 관계로, 아직 사용자 커뮤니티가 충분히 활성화 되어있지 않습니다. 이에 따라 트러블슈팅에 필요한 사용자 노하우를 얻기 어려웠습니다.
- 아직 프로젝트 초기 단계일 때 코드 레벨에서 호환성 높고 익숙한 도구로 빠르게 피봇팅 하는 것이 앞으로의 퍼포먼스를 위해 필요하다고 판단하고, FE 팀원 전원의 논의를 거쳐 Emotion으로 대체하였습니다.
- 처음에 PandaCSS를 도입했던 배경에 대해서는 아래의 내용을 참고해 주세요.
-
PandaCSS 도입 배경 (이전 문서)
-
기존 CSS-in-JS 라이브러리(styled-components, emotion)의 결점 고려
- CSS-in-JS로 작성된 스타일 코드들은 모두 빌드 단계에서 번들에 포함되므로, 전체 번들링 사이즈가 증가하는 단점이 있습니다.
- 또한 런타임 시점마다 CSS 코드를 생성하여 DOM에 주입하는 과정이 반복되므로, 잦은 변화와 갱신이 이루어지는 컴포넌트가 많아질수록 사용자의 체감 성능에 악영향을 미칠 수 있습니다.
- PandaCSS는 빌드 시점에 작게 원자화 된 CSS 코드들을 생성하여 컴포넌트에 주입하는 방식을 택하고 있습니다. 때문에 페이지 로딩 속도가 빨라지고, 번들링 사이즈도 줄어들 것으로 기대됩니다.
-
디자인 토큰 활용 가능성
- PandaCSS는 components, emotion와 달리 디자인 토큰 개념을 지원합니다.
- 디자인 토큰 : 여러 화면에서 공통적으로 사용될 디자인 요소를 정하여 둔 규칙
- PandaCSS는 components, emotion와 달리 디자인 토큰 개념을 지원합니다.
-
실사용 과정에서의 낮은 러닝 커브
- PandaCSS는 styled-components, emotion에서 지원하는 tagged template literal 방식의 스타일링을 거의 동일하게 지원합니다.
- 따라서 저희 팀원 모두 큰 러닝 커브 없이 프로젝트에 활용 가능할 것으로 판단했습니다.
-
기존 CSS-in-JS 라이브러리(styled-components, emotion)의 결점 고려
-
PandaCSS 도입 배경 (이전 문서)
- TanStack Query(구. React Query)는 React 환경에서 서버 데이터를 가져와 효율적으로 관리할 수 있는 서버 상태 관리 도구입니다.
- 레벨2 미션 과정에서 학습한 도구이기에, 팀원 모두 러닝 커브 없이 적용 가능하다는 이점을 고려했습니다.
- 데이터 페칭은 상태 관리, 캐싱, 에러 처리, 리트라이 로직, 그리고 리로딩 처리 등은 많은 개발자들에게 많은 비용을 요구합니다. 자동화된 캐싱과 간편한 에러 핸들링을 통해 보다 사용자 경험 개선에 비용을 사용할 수 있을 것이라 판단합니다.