반응형 레이아웃을 만들기 위해서는 미디어쿼리를 활용한 css, flexbox를 활용한 css 등 css의 활용이 여러모로 필요하다.
이번 포트폴리오에서는 material ui 디자인 프레임 워크를 사용하기로 했는데 예시에서 아래 코드처럼 스타일링 해주는걸 볼 수 있었다.
왜 이런식으로 스타일링을 해주는지와 다른 방식의 스타일링 방법(styled-components, Scss)에 대해 알아보겠다.
import React from 'react';
import { makeStyles } from '@material-ui/core/styles';
import Button from '@material-ui/core/Button';
const useStyles = makeStyles((theme) => ({
root: {
'& > *': {
margin: theme.spacing(1),
},
},
}));
export default function ContainedButtons() {
const classes = useStyles();
return (
<div className={classes.root}>
...
...
...
Material ui에서는 styling 해결책으로 자체 styles 패키지를 만들었다.
필수로 사용해야되는것은 아니지만, 다른 스타일링 솔루션들(styled-components, theme, CssModule, emotion)과 호환도 가능하다고 하다.
theme nesting, dynamic styles, self-support 등 여러가지 좋은 특징들을 갖고있다.
Material ui styling 솔루션은 styled-components나 emotion같은 다른 라이브러리들로부터 영향을 받았기 때문에 styled-components의 장점을 그대로 가져온다.
그럼 많이 들어봤던 styled-component의 장점부터 알아보자.
styled-components의 장점
✓ Automatic critical CSS
styled-components는 어떤 컴포넌트가 페이지에 렌더되는지 추적하고 스타일링을 하거나 하지 않을 수 있다(완전히 자동적으로!).
code splitting과 결합하여 필요한 최소한의 코드만 로드한다.
✓ No class name bugs
✓ Easier deletion of CSS
특정 컴포넌트와 스타일링이 결합되어 있기 때문에 사용되지 않는 컴포넌트를 찾아내고 삭제하기 쉽게 만들어준다.
✓ Simple dynamic styling
컴포넌트 기반의 스타일링이 그것의 props나 글로벌 theme을 간단하고 직관적으로 (다수의 수동적인 클래스 관리가 없어도) 사용할수 있게 만들어 준다.
✓ Painless maintenance
✓ Automatic vendor prefixing
Css를 그냥 작성하기만 한다면, styled-components에게 핸들링을 맡기면 개별적인 컴포넌트 스타일링의 장점을 느낄수 있다.
Material ui styling의 장점
✓ 위에 나온 styled-components의 장점을 갖는다
✓ 끝내주는 benchmark
✓ plugin API를 사용해 확장가능
✓ JSS가 core로 작동하기 때문에 고성능
✓ 적은 번들사이즈
Sass? SCSS?
Sass is a stylesheet language that’s compiled to CSS. It allows you to use variables, nested rules, mixins, functions, and more, all with a fully CSS-compatible syntax. Sass helps keep large stylesheets well-organized and makes it easy to share design within and across projects.
Sass는 CSS를 컴파일 해주는 스타일시트 언어이다.
Sass는 변수를 사용할 수 있게 해주며, 중첩 규칙, mixins, 함수 등 이런 모든 것들을 CSS와 같이 사용할 수 있게 해준다.
Sass는 잘 정돈되고 규모가 있는 스타일시트를 만들어주며 프로젝트를 넘어 다른 것들과 쉽게 공유할 수 있게 해준다.
Sass는 두가지 구문으로 나뉘어진다.
모든 유효한 CSS 스타일시트는 유효한 SCSS 파일이다(CSS 친화적)라는 모토를 갖고있는 SCSS와 들여쓰기 문법을 사용하는 Sass가 있다.
Sass vs styled-components
재사용성
Sass
BEM, OOCSS, ITCSS과 같은 방법론에 연결되있다.
코드베이스/팀에서 잘 작동
<-> BEM이 만드는 컴포넌트에서 읽을 수 없는 HTML을 생성하는 경우가 있다.
styled-components
props에 따라 변화가 통제되는 컴포넌트 중심의 구조
컴포넌트 공유에 따른 스타일 공유
<-> 컴포넌트가 포괄적일 수록, 복잡해지기 쉽고 디버깅과 확인이 어려워진다.
성능
Sass
styled-components가 겪은 성능문제로부터 자유롭다.
<-> DOM에서 컴포넌트 렌더링의 유연성때문에, 렌더링되지 않은 컴포넌트들도 로직에 따라 스타일이 소모될 것이다.
styled-components
스타일은 컴포넌트가 화면에 나온경우만 렌더링된다.
Next.js 혹은 Gatsby를 사용하는 SSR(Server side rendering)의 경우 Streaming Rendering API를 활용가능하다.
<-> emotion에 비해 뒤처진다.
pre-version 5의 경우, Context API와 작동할때 성능 이슈가 발생했었다.
확장성
Sass
환경에 가장 맞는 선택을 할 수 있다.(BEM/OOCSS/ITCSS/Functional CSS)
<-> 좋은 API 설계 대신 팀 그리고 코드리뷰 패턴에 의존하게 된다.
styled-components
프레임워크 설계 그리고 좋은 컴포넌트 기반 아키텍쳐 보장
BEM은 규율을 통해 안전을 확보한다. CSS in JS는 API설계를 통해 안전하게 된다. 전자는 작동하지만 쉽게 부숴질수 있고, 후자는 항상 작동한다.
Kyle Shevlin Twit
<-> 리액트/뷰는 괜찮지만 앵귤러는 emotion 추천, 러닝커브
결합성
Sass
Sass 변수의 사용(work with white label product)
styled-components
ThemeProvider의 사용으로 다른 테마 지원에 용이
컴포넌트 props에 대한 문서화(ie better-defined scope)
두가지 모두 Storybook, React Styleguist and Docz 같은 컴포넌트 라이브러리를 사용하기 좋다.
최후의 승자는?
현재 styled-component의 버전5가 출시 되지 않았기 때문에 성능이슈로 인하여 Sass를 선택하겠다는 원작자의 의견이다.
*다른 대안들 : Emotion, CSS Modules
결론
Sass와 styled-components 두가지 모두 다 장점/단점이 있다.
styled-components 재사용성, Props 사용, 복잡하지 않은 파일구조 등 장점이 있고,
Sass는 성능면에서 낫다고 한다.
포트폴리오에서는 Sass/SCSS를 활용하기로 했다.
그 이유는 크게 두가지다.
Css의 관련 스택의 발전(?) 순서가 Css -> Css 전처리기 -> styled-components 이런식으로 발전해나가는것 같은데 styled-component사용 이전에 Sass/SCSS를 경험해 보면 좋을것 같았고,
또한, styled-component는 재사용성이 가장 큰 장점이라고 느꼇는데 규모가 작은 프로젝트에서는 이런 장점을 살리기 힘들거라 판단했다.
References
