2021. 2. 1. 18:02ㆍ공부내용 공유하기
최근 지인으로부터 css in js 에 대한 불만 아닌 불만을 들을 기회가 있었다.
css, js, html이 각자 가지고 있는 역할이 분명히 다른데, (컴포넌트 위주의 웹 개발 환경이 득세하다보니) css in js등의 등장으로 그 역할이 모호해지고 있다는 것이다.
그 말에도 일리가 있다고 생각했다.
사실 구현의 측면에서는 그 역할이 사라지거나 불분명해지진 않았다.
하지만 컴포넌트 위주의 웹 개발에서는 html태그의 계층구조, 스크립트와 dom의 연결, bem등을 사용한 css클래스 네이밍 등의 작업에 많은 시간을 투자하지 않고 결과물을 낼 수 있게 된 것은 사실인 것 같다.
css in js가 가지고 있는 성능상의 이슈도 있고, 기술에는 정답이 없다고 생각하는 만큼 이러한 추세가 앞으로 또 어떻게 변할지는 모르겠다.
CSS-in-JS(Styled Components) vs CSS-inCSS(CSS Modules) 성능 비교
지난번 포스팅(CSS-in-JS에서 CSS-in-CSS로 바꿔야 하는 이유)에는 CSS-in-JS에서 CSS-in-CSS 방식으로 변경해야 하는 이유에 대해 설명했다. 요약해보면, 다음과 같다. 성능에 초점을 맞춘다면 , 개발 생산
blueshw.github.io
개인적으로는 CSS in JS(styled-component)를 사용하면서 매우 큰 만족을 느끼고 있는 편이다.
그 이유로는,
1. JS와 CSS영역의 관심사 분리가 편함
2. JS에서 넘기는 값을 유동적으로 받아서 스타일 처리가 가능
3. 필요시 JS와 CSS의 유기적인 결합이 가능
이정도 이유가 있겠다.
각 이유에 대한 예시는 다음과 같다.
1. JS와 CSS영역의 관심사 분리가 편함
컴포넌트 로직과 스타일 파일의 분리
컴포넌트 로직에서는 스타일링 된 컴포넌트의 네이밍만 확인하면 된다.
2. JS에서 넘기는 값을 유동적으로 받아서 스타일 처리가 가능
유저의 스크롤 top position을 js로 구해서, 스타일 컴포넌트에 props로 넘겨줄 수 있다.
해당 컴포넌트는 브라우저가 sticky를 지원하는 경우 sticky로 작동하고, 지원하지 않는 경우 props로 넘겨받은 top값으로 위치를 변경한다.
3. 필요시 JS와 CSS의 유기적인 결합이 가능
props로 받은 값을 파싱해서, 다양한 스타일링을 js를 통해 유기적으로 할 수 있다.
위에 있는 버튼 컴포넌트는 프로젝트의 모든 상황에서 사용 가능한 컴포넌트로 제작되어 굉장히 로직이 많다.
ex. 버튼 컴포넌트의 패딩을 구할 때, props로 받은 size 값에 따라 유동적인 사이즈 지정이 가능하다.