본문 바로가기

프론트엔드 공통

styled-component의 고찰

 

 

나에게  가장 선호하는  스타일링 라이브러리가 무엇이냐고 물어본다면  styled-component라고  대답할 것이다  그만큼  지금껏  개발할때  줄곧  스타일드 컴포넌트를 사용했다 .

 

최근에는 tailwind css 같은  라이브러리도 접했지만  아직까지도 스타일 컴포넌트를  주로 사용해왔다. 

 

하지만 최근 이런 의문이 들었다  내가 그토록 많이 사용하는 라이브러리라면  누군가  스타일드 컴포넌트의 장점과 단점을 물었을때  설명할 수 있는가?  질문을 던졌을때  대답을 못할것 같았다  그래서 이 참에 스타일드 컴포넌트의  장점은 무엇이고 또  단점은  무엇인지  정리해보려고 한다 .

 

styled-components의 장점 

 

공식문서에서 장점을 가지고 와봤다.

 

styled-components is the result of wondering how we could enhance CSS for styling React component systems. By focusing on a single use case we managed to optimize the experience for developers as well as the output for end users.

Apart from the improved experience for developers, styled-components provides:

  • Automatic critical CSS: styled-components keeps track of which components are rendered on a page and injects their styles and nothing else, fully automatically. Combined with code splitting, this means your users load the least amount of code necessary.
  • No class name bugs: styled-components generates unique class names for your styles. You never have to worry about duplication, overlap or misspellings.
  • Easier deletion of CSS: it can be hard to know whether a class name is used somewhere in your codebase. styled-components makes it obvious, as every bit of styling is tied to a specific component. If the component is unused (which tooling can detect) and gets deleted, all its styles get deleted with it.
  • Simple dynamic styling: adapting the styling of a component based on its props or a global theme is simple and intuitive without having to manually manage dozens of classes.
  • Painless maintenance: you never have to hunt across different files to find the styling affecting your component, so maintenance is a piece of cake no matter how big your codebase is.
  • Automatic vendor prefixing: write your CSS to the current standard and let styled-components handle the rest.

You get all of these benefits while still writing the CSS you know and love, just bound to individual components.

 

출처 :  https://styled-components.com/docs/basics#motivation

 

styled-components: Basics

Get Started with styled-components basics.

styled-components.com

 

 

대충 요약하면  

 

개발자를 위해  향상된 경험을 제공한다.

 

1 .Automatic critical CSS: styled-components는 페이지에 어떤 구성 요소가 렌더링되는지 추적하고 해당 스타일만 완전히 자동으로 주입한다. 코드 분할 시, 사용자가 필요한 최소한의 코드를 로드한다.

 

2. No class name bugs: 고유 클래스 명을 생성한다.

 

3. Easier deletion of CSS: 클래스 명을 어디에서 사용했는지 찾기 어려울 수 있다. styled-components는 스타일이 특정 구성 요소에 연결 되어 있어 구성 요소가 사용되지 않고 삭제되면 스타일 또한 삭제된다. (특정 구성 요소와 연결 되어 있기 때문에 style을 삭제 및 수정하기 쉽다는 얘기 같다.)

 

4. Simple dynamic styling: 전역 테마 또는 props를 기반으로 구성 요소의 스타일을 간단하고 직관적으로 적용할 수 있다.

 

5. Painless maintenance: 코드베이스가 크더라도 유지보수하기 쉽다.

 

6. Automatic vendor prefixing: CSS를 현재 표준에 맞게 작성하면 나머지는 styled-components가 알아서 해준다는 얘기인듯.

 

 

내가 생각하는 장점은,

 

1. class 명과 그에 해당하는 style을 찾기 편해 유지보수가 쉽다는 점

 

2. component처럼 작성하고 추상화하여 React의 장점을 극대화 시킬 수 있다는 점

 

3. React와 props를 공유하여 style 확대 가능, 변경이 가능하다는 점

 

4.고유한 className을 적용해준다는 점

 

정도로 요약해볼 수 있을 것 같다.

 

 

styled-components의 단점 


대부분의 CSS in JS 라이브러리는 런타임에 하나 이상의 태그를 사용하거나 API를 사용하고 CSSOM 내에서 스타일을 직접 관리하여 DOM에 삽입한다. SSR 중에는 항상 렌더링 된 HTML 내부에 태그로 추가된다.

단점은 번들 크기와 관련이 있다.

1. 동적 스타일을 지정하려면 추가로 런타임 라이브러리가 필요하다. 라이브러리가 추가되면서 번들의 크기가 커진다.

 

2. SSR에 인라인 된 경우, 기본적으로 캐시가 되지 않아 요청이 있을 때마다 브라우저에 제공 되어야 한다.

 

출처: https://css-tricks.com/a-thorough-analysis-of-css-in-js/

 

A Thorough Analysis of CSS-in-JS | CSS-Tricks

Wondering what’s even more challenging than choosing a JavaScript framework? You guessed it: choosing a CSS-in-JS solution. Why? Because there are more than

css-tricks.com

 

 

 

1. 자바스크립트와 별도로 캐시할 수 없다.
2. CSS in CSS에 비해 느리다.
3. 러닝 커브가 있다.

 

https://www.cbinsights.com/research/team-blog/css-in-js-traditional-css/

 

CSS-In-JS Vs Traditional CSS — Which Should You Use? - CB Insights Research

At CB Insights, we adopt a traditional CSS approach. Here's why.

www.cbinsights.com

 

 

그리고 오히려 Component와 비슷하게 작성되어 코드 상에서 Component와 Style을 구분하기 어려운 단점도 있을 것 같다. 예를 들어 Button 컴포넌트와 styled-components로 작성된 Button 스타일이 존재할 때 구분하기 번거로울 것이라 생각했다. 이름을 다르게 짓거나 import 할 때 이름을 바꾸는 식으로 해야 할 것이다. 작은 프로젝트에선 충분히 구분이 가능하겠지만 대형 프로젝트라면 이런 상황이 발생할 수도 있을 것 같다. 단지 나의 추측이다.

 

'프론트엔드 공통' 카테고리의 다른 글

Atomic Design Pattern: 아토믹 디자인 패턴  (0) 2023.01.10
[개발 지식] - 쿠키와 세션  (0) 2022.10.30
[axios] - interceptors  (0) 2022.10.20