업무를 하며 느낀 styled-component와 sass 컨셉

https://velog.io/@4_21ee/TIL-49-SCSS-Styled-components

 

스타트업의 프론트엔드 엔지니어인 나는 다음의 업무들을 하고 있다.

 

1. 마케팅팀과 협업하여 자사 랜딩페이지 유지보수(줄여서 웹작업)
2. SQL로 데이터 추출
3. 내부 플랫폼 유지보수
4. 새로운 어드민(관리자페이지) 작업(0부터 만드는 중)

위 4가지 업무중 웹작업(1번)과 어드민(4번)을 통해 styled-component와 sass의 컨셉을 실감할 수 있었다.

sass는 어드민 작업에 들어가면서 처음 사용하였고

styled-component는 교육생시절부터 써온 친숙한 스택이다.

 

웹 작업은 마케팅지원이 주된 업무로써 가장 빠른방법으로 다양한 실험을 하고 있는 홈페이지이다.

그러다보니 각 페이지의 ui가 모두 다르다.

때문에 컴포넌트간의 의존성을 없애버리는 styled-component를 사용했던 것이다.

 

styled-component가 각 컴포넌트의 스타일을 독립시킨다는 개념을 알고 있었지만 의식하지 못한채 사용하고 있었다.

 

하지만 이번에 새로 들어가는 어드민작업은 한번 만들어놓으면 변화가 크게 없는 홈페이지기 때문에

독립성을 유지하기보다는 체계적인 스타일링 구조가 필요하다.

 

때문에 sass를 사용하여 global style을 변수로 저장하고, 필요할때마다 재사용하는 방법을 선택한 것이다.

 

회사에서는 스택을 왜 사용하는지 알고 쓰는 사람을 원하지만, 정작 입사한 나는 styled-component를 왜 사용하는지 전혀 모른채 사용하고 있었다.

 

이번 계기를 통해 왜 면접들에서 '스택의 컨셉을 이해하고 있는지'를 물어보는지 알 수 있었다.

 

만약 이번 어드민작업에서도 styled-component를 사용했다면 반복되는 스타일을 매번 다시 작성하는 리소스 낭비를 했을 것 같다.

(물론 어느정도 재사용을 하긴 했겠지만)

 

---

이 페이지 에서 SASS와 styled-component의 특징을 비교한 글을 볼 수 있다.

 

scss

렌더링되는 컴포넌트 파일에 작성되어 있는 스타일만 렌더링하는 styled-component와 달리, 브라우저에 보이지 않는 컴포넌트 까지 웹문서의 스타일 정보로 읽히기 때문에 불필요한 컴파일 과정이 추가된다.

 

기본적으로 js 파일과는 분리되어 있는 구조이기 때문에 컴포넌트의 변화에 대한 반응성이 비교적 떨어진다.

 

styled-components

 

css in js 방식이기에 해당 컴포넌트가 렌더링될때만 해당 스타일 정보를 읽는다. 이는 장점이자 단점인데, 컴포넌트가 렌더링 될 때마다 스타일 정보를 가져온다. 

 

동적인 웹사이트에서는 컴포넌트의 상태값 전환도 활발하기 때문에, 컴포넌트 인터렉션이 활발할수록 자주 렌더링 될 것이다.

렌더링은 깜빡임을 유발하기 때문에 인터렉션이 활발한 페이지에서의 styled-component는 좋지 않은 방식이다.

반면 css in css는 html문서에서 이미 읽혀져있기 때문에 첫 로딩이 길더라도 그 이후 추가적인 렌더링은 상대적으로 적다.