Component Driven Development(CDD)의 필요성과 이점에 대해서 이해한다.
구조적으로 CSS를 작성하는 방법의 발전과 이유에 대해서 이해한다.
CSS 방법론들의 특징과 장단점을 이해한다.
CDD (Component Driven Development)
: 레고처럼 조립해 나갈 수 있는 부품 단위로 UI 컴포넌트를 만들어 나가는 개발(상향식 개발)
🍎 CSS의 발전 과정
- 프로젝트의 규모나 복잡도가 점점 커지고 함께 작업해야 할 팀원 수도 많아짐
- 모바일이나 태블릿을 비롯한 다양한 디바이스들의 등장으로 웹사이트들이 다양한 디스플레이를 커버해야 함
근데 CSS를 작성하는 일관된 패턴이 없어서 곤란
➡ CSS 작업을 효율적으로 하기 위해 구조화된 CSS의 필요성이 대두되었고, CSS를 구조화하는 방법에 대한 연구가 필요해 졌다.
이러한 문제점들을 해결하기 위해 CSS 전처리기(CSS Preprocessor)라는 개념이 등장!
🍒 CSS 전처리기
CSS가 구조적으로 작성될 수 있게 도움을 주는 도구
이를 통해 CSS 파일들을 잘 구조화할 수 있게 되었고, 최소한 CSS 파일을 몇 개의 작은 파일로 분리할 수 있는 방법이 생겼다!
- 많은 반복적인 작업
- Color 값을 찾는 일
- tag를 닫는 일
- 뿐만 아니라 클래스의 상속과 같은 사항으로 점점 CSS 문서는 양이 많아 짐
- 이로 인해 이후 유지관리에 많은 영향을 끼침
위와 같은 "CSS의 문제점"들을 프로그래밍 개념(변수, 함수, 상속 등)을 활용하여 해결해 나갈 수 있다.
BUT! CSS 전처리기(CSS Preprocessor) 자체만으로는 웹 서버가 인지하지 못하기 때문에 각 CSS 전처리기에 맞는 Compiler를 사용해야 하고,
컴파일을 하게 되면 실제로 우리가 사용하는 CSS 문서로 변환된다.
🍒 SASS (Syntactically Awesome Style Sheets)
가장 유명한 CSS 전처리기로, CSS를 확장해 주는 스크립팅 언어이다.
즉, CSS를 만들어주는 언어로서 자바스크립트처럼 특정 속성(ex. color, margin, width 등)의 값(ex. #ffffff, 25rem, 100px 등)을 변수로 선언하여
필요한 곳에 선언된 변수를 적용할 수도 있고,
반복되는 코드를 한 번의 선언으로 여러 곳에서 재사용할 수 있도록 해 줌
- 변수 선언은
$붙여서 선언.
ex)$base-color: rgba(198, 83, 140, 0.88)
➡ SASS는 SCSS 코드를 읽어서 전처리한 다음 컴파일해서 전역 CSS 번들 파일을 만들어 주는 전처리기(preprocessor)의 역할을 한다.
하지만 얼마 지나지 않아서 SASS가 ‘CSS의 구조화’를 해결해 주는 것의 장점보다 다른 문제들을 더 많이 만들어낸다는 것이 밝혀진다
- 전처리기(preprocessor)가 내부에서 어떤 작업을 하는지는 알지 못한 채, 스타일이 겹치는 문제를 해결하기 위해 단순히 계층 구조를 만들어 내는 것에 의지하게 되었고, 그 결과 컴파일된 CSS의 용량은 어마어마하게 커지게 된 것...
🍒 CSS 방법론
CSS 전처리기의 문제를 보완하기 위해 BEM, OOCSS, SMACSS 같은 CSS 방법론이 대두되었다.
- 각 CSS 방법론의 특징과 장, 단점
각각의 장단점이 있으나 결국 세 방법론 모두 같은 지향점을 가지고 있다.
- 코드의 재사용
- 코드의 간결화(유지 보수 용이)
- 코드의 확장성
- 코드의 예측성(클래스 명으로 의미 예측)
위와 같은 CSS 방법론들은 같이 일하는 팀 동료들의 팀워크와도 연결되기 때문에 여러 팀원이 함께 작업하는 상황에서 CSS 작성에 있어서 방법들을 규칙으로 정해두는 것은 매우 중요한 요소라고 할 수 있다.
하지만 이러한 방법론들에서도 문제점이 발생하기 시작...
- 클래스명 선택자가 장황해짐.
- 이런 긴 클래스명 때문에 마크업이 불필요하게 커지며,
- 재사용하려고 할 때마다 모든 UI 컴포넌트를 명시적으로 확장해야만 함
SASS와 BEM도 고치지 못했던 몇 가지 문제가 바로
언어 로직 상에 진정한 캡슐화(encapsulation : 객체의 속성과 행위를 하나로 묶고 실제 구현 내용 일부를 외부에 감추어 은닉하는 개념)의 개념이 없다는 것.
이로 인해 개발자들이 유일한 클래스명을 선택하는 것에 의존할 수밖에 없었다.
🍒 캡슐화(encapsulation)
애플리케이션으로 개발 방향이 진화하면서 컴포넌트 단위의 개발은 캡슐화의 중요성을 불러왔다.
BUT,
CSS는 컴포넌트 기반의 방식을 위해 만들어진 적이 한 번도 없었기 때문에
CSS도 컴포넌트 영역으로 들이기 위해서 CSS-in-JS가 탄생해, 이 문제를 정확히 해결
다음 글에서는 CSS-in-JS의 대표격인 Styled Components에 대해 알아보자!
