-
Notifications
You must be signed in to change notification settings - Fork 1
CSS in CSS CSS in JS
Sangwoo edited this page Nov 20, 2020
·
3 revisions
가볍고 인터랙션이 별로 없는 정적인 서비스를 만든다면 어떤 방식을 선택하더라도 크게 무리는 없다. 다만, 인터랙션이 풍부하거나 페이지 하나가 포함하는 컴포넌트 수가 많은 경우에는 Styled Components와 같은 CSS-in-JS 방식이 아닌, CSS Modules와 같은 CSS-in-CSS
방식으로 작업하기를 권장한다.
- 컴포넌트로 생각하기— 더이상 스타일시트의 묶음을 유지보수 할 필요가 없습니다. CSS-in-JS는 CSS 모델을 문서 레벨이 아니라 컴포넌트 레벨로 추상화합니다(모듈성).
- CSS-in-JS는 JavaScript 환경을 최대한 활용하여 CSS를 향상시킵니다.
- "진정한 분리 법칙"—스코프가 있는 선택자로는 충분하지 않습니다. CSS에는 명시적으로 정의 하지 않은 경우, 부모 요소에서 자동으로 상속되는 속성이 있습니다. jss-isolate 플러그인 덕분에 JSS 규칙은 부모 요소의 속성을 상속하지 않습니다.
- 스코프가 있는 선택자—CSS는 하나의 전역 네임스페이스만 있습니다. 복잡한 애플리케이션 내에서 선택자 충돌을 피할 수 없습니다. BEM과 같은 네이밍 컨벤션은 한 프로젝트 내에서는 도움이 되지만, 서드파티 코드를 통합할 때는 도움이 되지 않습니다. JSS는 JSON으로 표현된 것을 CSS로 컴파일 할 때, 기본적으로 고유한 이름을 생성합니다.
- 벤더 프리픽스—생성된 CSS 규칙은 자동적으로 벤더 프리픽스가 붙어있으므로 생각할 필요가 없습니다.
- 코드 공유—JavaScript와 CSS사이에 상수와 함수를 쉽게 공유할 수 있습니다.
- 현재 화면에 사용중인 스타일만 DOM에 있습니다(react-jss).
- 죽은 코드 제거
- CSS 유닛 테스트!
- 학습 곡선(Learning curve)
- 새로운 의존성
- 신규 팀원이 코드베이스에 적응하기 어렵게 만듭니다. 프론트엔드를 처음 접하는 사람들은 "더" 많은 것을 배워야합니다.
- 현상 유지를 위한 도전 (꼭 단점은 아니다.)
성능에 초점을 맞춘다면 CSS-in-CSS
, 개발 생산성에 초점을 맞춘다면 CSS-in-JS
를 사용하는 편이 낫다. 어떤 방식이 더 낫다고 단정할 수는 없으며, 서비스의 용도와 목적에 따라 적절한 선택이 필요하다.