CDD(Component Driven Development)
부품 단위로 UI 컴포넌트를 만들어 나가는 개발
구조적인 CSS 작성 방법
구조화된 CSS가 필요하게 된 이유
프로젝트의 규모나 복잡도가 점점 커짐
팀원의 수도 증가
모바일이나 태블릿 등 다양한 디바이스가 등장(다양한 디스플레이)
CSS 전처리기(CSS Preprocessor)
SASS(Syntactically Awesome Style Sheets)
$base-color: rgba(255, 255, 255, 0.5)
.alert {
border: 1px solid $border-dark
}
.button {
color: $border-dark
} 특정 속성을 변수로 선언하여 필요한 곳에 선언된 변수 사용 가능
반복되는 코드를 한 번의 선언으로 재사용 가능
내부에서 어떤 작업을 하는지 알지 못한 채 단순히 계층구조를 만들어내는 것에 의지하게 되었고 컴파일된 CSS의 용량이 매우 커짐
BEM(Block, Element, Modifier)
.header__navigation--navi-text {
color: red;
} Block : 전체를 감싸고 있는 블럭 요소(__전, 여기서는 .header)
Element : 블럭이 포함하고 있는 한 조각(--전, navigation)
Modifier : 블럭 또는 요소의 속성 (블록이나 엘리먼트의 외관, 상태를 변할 수 있게 하는 부분)
클래스명 선택자가 장황해지고 마크업이 불필요하게 커지며, 재사용할 때마다 모든 UI 컴포넌트를 명시적으로 확장해야만 했음
SASS와 BEM의 공통 문제점은 캡슐화의 개념이 없어 개발자들이 유일한 클래스명을 선택하는 것에 의존할 수 밖에 없었다는 것
CSS 전처리기의 문제를 보완하려는 방법론의 지향점
- 코드의 재사용
- 코드의 간결화 (유지보수 용이)
- 코드의 확장성
- 코드의 예측성 (클래스 명으로 의미 예측)
Styled-Component
const Button = styled.a`
display: inline-block;
border-radius: 3px;
padding: 0.5rem 0;
margin: 0.5rem 1rem;
width: 11rem;
`;Automatic critical CSS
화면에 어떤 컴포넌트가 렌더링되었는지 추적해서 해당하는 컴포넌트에 대한 스타일을 자동으로 삽입. 최소한의 코드만으로 화면 렌더링 가능
No class name bugs
스스로 유니크한 className을 생성하므로 중복이나 오타로 인한 버그 감소
Easier deletion of CSS
기존에는 삭제한 컴포넌트에 해당하는 스타일 속성을 찾기위해 CSS 파일 안의 className을 찾아야했으나 Styled-Component는 스타일 속성이 컴포넌트와 연결되어있으므로 컴포넌트 삭제 시 스타일 속성도 같이 삭제됨
Simple dynamic styling
일일이 수동으로 관리할 필요없이 props나 전역 속성을 기반으로 컴포넌트에 스타일 속성을 부여하므로 간단하고 직관적
Painless maintenance
컴포넌트에 스타일을 상속하는 속성을 찾아 다른 CSS 파일들을 검색하지 않아도 되기 때문에 코드의 크기가 커져도 유지 보수가 어렵지 않음
Automatic vendor prefixing
개별 컴포넌트마다 기존의 CSS를 이용하여 스타일 속성을 정의
