2021-09-22 Scss, styled-components

1. css의 한계

(1) 클래스명을 작성하는 번거로움

(2) 방대한 스타일 정보로 인한 파일의 크기

 

→ scss, styled-components의 등장

 

 

2. Scss

- Sass 버전3에서 등장하였으며 Saas의 모든 기능을 구현하면서 CSS 문법과 완전히 호환된다.

- 그 자체로 웹에서 돌아갈 수 없기 때문에 전처리기로 작성된 후 CSS로 컴파일 되어야 한다. (Gulp, Webpack, Parcel 등)

- 변수 사용이 가능한다.

- 연산자가 사용 가능하다 : +, -, /, *, %, ==, != (단 +, -는 단위를 통일시켜서 사용해야 한다.)

- Nesting이 가능하다. (상위 요소를 참조할 때는 &를 사용한다.)

- Mixin을 사용할 수 있다. (선언 : @mixin, 사용 : @include)

- 커스텀 함수를 사용할 수 있다. (정의 : @function, 리턴값 사용 : @return)

- if절 분기문을 사용할 수 있다. (@if 표현식  { ... } @else { ... })

- 반복문을 사용할 수 있다 : @for, @each, @while

- 가독성과 디버깅에서 보완이 되었으나 여전히 클래스명을 고민해야 한다.

 

※ Sass (Syntactically Awesome StylesSheets)

- CSS로 해석, 컴파일되는 스크립트 언어로 변수 사용, Nesting 등의 특징을 가진다.

- mixin 선언 방식, { }와 ; 의 유무에서 Scss와 차이를 지닌다.

 

 

3. styled-components

- html 태그별로 클래스명이 자동으로 부여된다. (클래스명에 대한 고민 해결)

- 기존 컴포넌트가 가지던 재사용성이라는 장점을 갖춘다.

- 컴포넌트 속성인 prop 기능을 통해 jsx에서 넘겨주는 값을 css에서 활용 가능하다.

- 스타일 정보가 많거나 프로젝트 규모가 커지면 js 파일이 방대해질 수 있다. (가독성 혹은 디버깅 문제 발생 가능)

 

 

4. Scss vs styled-components

- Scss는 css in css 방식이기 때문에 js와 분리되어 있으며 브라우저에 렌더링 되지 않는 컴포넌트더라도 컴파일이 이루어진다. (불필요)

- styled-components는 컴포넌트가 렌더링될 때 해당 스타일 정보를 읽는다. 따라서 렌더링되지 않는 컴포넌트의 스타일 정보는 무시할 수 있지만 렌더링이 이루어질 때마다 스타일 정보를 읽어와야 한다는 단점이 있다.

 

→ 따라서 동적인 이벤트가 많은 페이지의 경우 컴포넌트의 렌더링이 잦기 때문에 Scss를 활용하는 방법이 처음에 읽어오는 정보는 많더라도 추가 렌더링 관점에서 효율적이라고 볼 수 있다.