hmk run dev

emotion(css-in-js)과 nextjs 본문

카테고리 없음

emotion(css-in-js)과 nextjs

hmk run dev 2024. 5. 5. 20:19

nextjs와 emotion(css-in-js)을 같이 사용하다.
두 개의 조합이 별로 좋지 못하다는 생각이 들어 emotion을 사용해 왔던 이유와
조합이 좋지 못한 nextjs와 계속 같이 사용을 하는 게 맞을지에 대한 판단을 하기 위해 정리해보려고 합니다.


emotion/css-in-js 방식의 장단점

 

장점


가독성
- css 혹은 id 같은 선택자로 css를 작성하지 않고 태그명 자체를 개별로 명시해서 사용할 수 있음

스타일 충돌 방지
- emotion을 이용한 스타일링은 개발자가 임의로 선택자를 지정해 작성한 css와 달리 개별 스코프를 가지며 css 충돌 가능성이 매우 낮음


상태에 따른 스타일 변경용이
- emotion 태그 내에 js코드를 혼합해서 작성이 가능해 react의 state에 따른 스타일 구현하기가 비교적 편함

export const Description: React.FC<IProps> = ({
  label,
  labelWidth,
  content,
}) => {
  return (
    <Wrapper>
      <LabelArea width={labelWidth}>{label}</LabelArea>
      <ContentArea>{content}</ContentArea>
    </Wrapper>
  );
};

/** emotion styled */
export const Wrapper = styled.section`
  display: inline-flex;
  align-items: center;
  gap: 0.625rem;
  width: 100%;
  border-top: 1px solid ${COLOR.SKELETON.TEXT_03};
  border-bottom: 1px solid ${COLOR.SKELETON.TEXT_03};
  border-right: 1px solid ${COLOR.SKELETON.TEXT_03};
  margin-bottom: -1px;
`;

export const LabelArea = styled.span<{ width?: string }>`
  display: flex;
  width: ${(props) => props.width ?? '12rem'};
  padding: 0.75rem 1.5rem;
  align-items: center;
  gap: 0.5rem;
  align-self: stretch;
  background: ${COLOR.UI_UP_02};
  color: ${COLOR.TEXT_D_02};
  border-left: 1px solid ${COLOR.UI_UP_UI_STROKE};
  border-right: 1px solid ${COLOR.UI_UP_UI_STROKE};

  ${BODY_BODY_LONG_2}
`;

export const ContentArea = styled.span`
  display: flex;
  align-items: center;
  gap: 1rem;
  padding: 0 0.75rem;

  color: ${COLOR.TEXT_D_01};
  ${BODY_BODY_LONG_2}

  input {
    padding-left: 0;
    max-width: 7rem;
  }
`;

 

 



단점


nextjs와 조합
- RSC(서버컴포넌트), SSR과 같은 방식에서 지원이 미흡하거나 아예 사용자체가 불가
아래 이슈들이 모두 해결되어야 사용가능하지 않을까 싶음
https://github.com/emotion-js/emotion/issues/2928

성능
- css-in-js 방식은 컴포넌트가 렌더링 될 때 css 스타일을 따로 직렬화하는 과정이 필요함 & js 번들크기 증가


정량적인 성능 측정은 아래 글을 참고하면 좋을 것 같다.  
https://www.samsungsds.com/kr/insights/web_component.html

 

웹 컴포넌트 스타일링 관리 CSS-in-JS vs CSS-in-CSS | 인사이트리포트 | 삼성SDS

HTML(Hypertext Markup Language)이 처음 등장한 1991년에는 CSS(Cascading Style Sheets)가 없었습니다. 웹 이용자들이 늘어나면서 디자인에 대한 요구가 커졌고 웹 고안자들은 HTML을 꾸며주는 언어의 필요성을

www.samsungsds.com


 

결론


나열해 보니 DX vs 성능/nextjs와 조합 측면에서 선택을 해야 할 것 같긴 하다.

확실히 개발경험은 emotion 쪽이 더 가독성 좋고 명시적인 스타일링이 가능했었던 것 같아서 만족하며 쓰는 중이다.

현재 상황에선 nextjs에서 emotion 관련된 이슈를 빨리 해결해 주면 best이긴 하나... 몇 년째 개선의 여지가 안 보인다...

결론은 성능상 이점이 있는, 그리고 표준에 맞는 css-in-css 방식을 사용해 nextjs에서 제공하는 기능(SSR, SSG, ISR, RSC)등을 이용하는 쪽으로 개발할 예정이다.

 

이에 더해 next 측에서도 스타일링 방법으로 PostCss나 Tailwind CSS를 사용하는 것을 권장하고 있다.  
https://nextjs.org/docs/app/building-your-application/styling/css-in-js#:~:text=we%20recommend%20using%20CSS%20Modules%20or%20other%20solutions%20that%20output%20CSS%20files%2C%20like%20PostCSS%20or%20Tailwind%20CSS.

 

Comments