언제 어떤 도구를 쓰는게 맞는지 생각해보자.
TLDR :
- 생산성 : Css-in-js
- 유지보수성, 확장성 : tailwind CSS
Utility first CSS
Utility first CSS와 CSS-in-JS를 논하기에 앞서, 디자인 토큰의 개념에 대해 이해해야 한다.
디자인 토큰은 디자인에 관련한 개발자와 디자이너의 인터페이스라 할 수 있다.
이 디자인 토큰을 HTML에 className을 통해 API처럼 반영할 수 있도록 해주는 것이 tailwindcss다.
즉 className이 하이레벨 다자인 API(인터페이스)다.
좀 더 알아보기 : https://fe-developers.kakaoent.com/2022/220505-how-page-part-use-atomic-design-system/
(약간의 상식 : jsx는 대문자 태그는 변수, 소문자 태그는 리터럴 취급한다)
css를 디자인 토큰을 추상화한 className으로 작업할 수 있다.
이 유틸리티 퍼스트 클래스는 디자인의 횡단관심사이다.
const ConfirmButton = (props) => {
const { className, ...rest } = props;
return (
<button
className={classnames(
'bg-black text-red-400',
className,
)}
{...rest}
></button>
);
});
<ConfirmButton
className="bg-white text-blue-400 rounded"
/>
// 팁 : 타입스크립트를 사용할 경우 다음과 같이 작업하는 것 가능.
interface CommentProps extends HTMLAttributes<HTMLDivElement> {
name: string;
}
function Comment({ name, children, ...props }: CommentProps) {
return (
<div {...props}>
<Text>{name}</Text>
<Text>{children}</Text>
</div>
)
}
개발자와 디자이너 사이에 퍼블리셔가 있는 경우,
해당 클래스 명으로 마크업을 요청하면, 개발 시 좀 더 디자인적인 시맨틱함을 얻을 수 있다.
또한 스타일 시트와 소스코드를 왔다갔다 할 필요가 없어서 좋다.
단점은 다음과 같다.
- html에 디자인의 캡슐화가 어느정도 누출된다. 그리고 클래스 명이 생각보다 엄청나게 길어질 수 있다.
- 애니메이션 같이 사전 컴파일이 어렵고 동적인 기능이 필요한 경우 프리셋을 제공하기 어렵다.
CSS-In-JS
css-in-js는 반대로 클래스명이 없는 만큼, 컴포넌트 단위로 스타일을 캡슐화한다.
즉 단일 진실 원천이 클래스 명이 된다.
(물론 외부에서 주입할 수 있다. 이 경우 css-in-js의 스타일과 동시 적용된다.)
즉 바운더리를 명확하게 정하고, variant 기반 API로 커뮤니케이션 하는 소프트웨어 덩어리라 보면 된다.
디자인(시각화)와 인터랙션에 대한 단일 책임을 해당 컴포넌트 내부로 캡슐화 하는 개념이라고 (개인적으로)생각한다.
className으로 추상환 디자인 API 대신 css를 좀더 직접적으로 이용한다.
즉 디자인토큰을 직접 사용한다.
반대로 컴포넌트 API를 좀 더 하이레벨로 개발할 수 있다.
위의 TailwindCSS 코드를 styled-components로 옮기면 아래와 같이 될 것이다.
const ConfirmButton = styled.button`
background-color: "var(--bg-black)";
color: "var(--text-red)";
font-weight: "var(--font-size-400)";
`;
장점은 tailwindCSS를 사용할 때보다 하이 레벨의 API를 사용할 수 있다.
또한 모든 것이 코드인 만큼 라이브러리에 따라 막강한 기능을 제공하는 것들이 많다.
예시 : 컴포넌트의 다양한 변형을 쉽게 개발할 수 있게 해주는 stitches
단점은 자칫 잘못하면 발생하는 성능 문제, 개발자가 CSS를 직접 저수준에서 다뤄야 한다는 점이라 할 수 있겠다.
어떤 도구가 좋을까?
다른 게시글로 갈음합니다.
https://itchallenger.tistory.com/781
참고 :
헤드리스 UI 프레임워크와 css-in-js 프레임워크를 둘 다 유지보수하는 메인테이너가 두 개를 동시에 사용하는 이유
https://itchallenger.tistory.com/779
https://itchallenger.tistory.com/781
https://itchallenger.tistory.com/594
https://itchallenger.tistory.com/620
'FrontEnd' 카테고리의 다른 글
개인적으로 생각해본 컴포넌트 설계론 + 카카오 FE 기술블로그 염탐 (0) | 2022.07.08 |
---|---|
Styled-Components의 비밀 파헤치기 (0) | 2022.07.08 |
새로운 리액트 공식문서로 배우는 Context API 2편 : 리듀서와 컨텍스트로 애플리케이션 확장하기 (0) | 2022.07.06 |
새로운 리액트 공식문서로 배우는 Context API 1편 : 프롭 드릴링 해결하기 (0) | 2022.07.05 |
새로운 리액트 공식문서로 배우는 Reducer (0) | 2022.07.05 |