Unit 3 - [React] Custom Component

2023-06-16(금)

 

Component-Driven Development

(CDD)

 

기획자로부터 하나의 기획이 들어온 상황에서, 디자이너와 개발자가 협력하여 개발진행이 된 후 페이지가

모두 완성되었는데, 다른 페이지에 적용되는 버튼에 대한 추가적인 기획이, 이전에 요청받았던 버튼을 똑같이 사용하도록

요청하는 기획자에 요청에 디자이너와 개발자는 이 부분을 새로 만들어야 할까요?

 

이러한 상황에선, 여러 프로젝트 혹은 여러 팀 간에 같은 UI 컴포넌트를 공유한다면 이런 고민을 하지 않아도 됩니다.

 

하지만 디자인과 개발 단계에서부터 재사용할 수 있는 UI 컴포넌트를 미리 디자인하고 개발하면

이런 고민을 해결할 수 있습니다.

 

이러한 고민을 해결하기 위한 개발 방법이 Component-Driven Development (CDD) 입니다.

 

레고처럼 조립해 나갈 수 있는 부품 단위로 UI 컴포넌트를 만들거 나가는 개발을 진행할 수 있습니다.

실제로 CDD 방법을 활용하여 UI를 구축하는 사이트도 많은데 

EX) BBC사이트

 

즉 CDD란 = 부품 단위로 UI 컴포넌트를 만들어 나가는 개발 방법이다.

---

CSS in JS

= 말 그대로 자바스크립트에서 CSS를 작성하는 방식

-> CSS도 컴포넌트 영역으로 불러들일 수 있게 

 

구조화된 CSS?

= 프로젝트의 규모나 복잡도가 점차 커지면서 함께 작업해야하는 팀원 수도 많아짐에 따라 CSS를 작성하는 일관된

패턴이 없다는 것을 개발자들의 걸림돌이 되었고, 설상가상으로 모바일이나 태블릿을 비롯한

다양한 디바이스들의 등장으로 웹사이트들이 다양한 디스플레이를 커버해야 하기 때문에 CSS는 더 복잡해지게 됨

 

이를통해 좀 더 CSS를 효율적으로 작업하기 위해 구조화된 CSS의 필요성이 중요해졌고, CSS를 구조화하는 방법이 나옴

 

이러한 문제점들을 해결하기 위해 CSS 전처리기

CSS Preprocessor 이라는 개념이 등장했습니다 = CSS가 구조적으로 작성될 수 있게 도움을 주는 도구

 

우리가 흔히 CSS 문서를 작성할 때는 많은 반복적인 작업을 요구하고 Color 값을 찾는일, tag를 닫는 일 등 번거로운

작업 역시 포함되어 있습니다. 이런 css 문제점들을 프로그래밍 개념을 활용하여 해결할 수 있습니다.

 

하지만 이 CSS 전처리기 자체만으로 웹 서버가 인지하지 못하기 때문에 각 CSS 전처리기에 맞는 컴파일러를 사용하고

컴파일 하게 되면 우리가 사용하는 CSS 문서로 변환이 되빈다.

 

이를 통해 CSS 파일들을 잘 구조화 할 수 있게 되었고, 최소한 CSS 파일을 몇 개의 작은 파일로 분리할 수 있게되었다.

 

---

SASS (Syntactically Awesome Style Sheets)

= css 전처리기 중 가장 유명한 전처리기 / css를 확장해 주는 스크립팅 언어

 

즉, CSS를 만들어주는 언어로서 자바스크립트처럼 특정 속성(ex. color, margin, width 등)의 값(ex. #ffffff, 25rem, 100px 등)을 변수로 선언하여 필요한 곳에 선언된 변수를 적용할 수도 있고,
반복되는 코드를 한 번의 선언으로 여러 곳에서 재사용할 수 있도록 해 주는 등의 기능을 가졌습니다.

그래서 SASS는 SCSS 코드를 읽어서 전처리한 다음 컴파일해서 전역 CSS 번들 파일을 만들어 주는 전처리기(preprocessor)의 역할을 합니다.

하지만 얼마 지나지 않아서 SASS가 ‘CSS의 구조화’를 해결해 주는 것의 장점보다 다른 문제들을 더 많이 만들어낸다는 것이 밝혀집니다.

결국 우리는 전처리기(preprocessor)가 내부에서 어떤 작업을 하는지는 알지 못한 채, 스타일이 겹치는 문제를 해결하기 위해 단순히 계층 구조를 만들어 내는 것에 의지하게 되었고,
그 결과 컴파일된 CSS의 용량은 어마어마하게 커지게 되었습니다.

 

이를 보완하기 위해 BEM, OOCSS , SMACSS 같은 CSS 방법론이 생겨났습니다.

각각의 장단점이 있으나 결국 세 방법론 모두 같은 지향점을 가지고 있습니다.

 

방법론의 공통 지향점은 다음과 같습니다.

1. 코드의 재사용

2. 코드의 간결화( 유지 보수 용이 )

3. 코드의 확장성

4. 코드의 예측성 ( 클래스 명으로 의미 예측)

 

대표적인 CSS 방법론으로는 BEM이 있습니다. 
BEM이란 Block, Element, Modifier로 구분하여 클래스명을 작성하는 방법이며, Block, Element, Modifier 

각각은 —와 __로 구분합니다.
클래스명은 BEM 방식의 이름을 여러 번 반복하여 재사용할 수 있도록 하며 HTML/CSS/SASS 파일에서도 

더 일관된 코딩 구조를 만들어 줍니다.

하지만 이러한 방법론들에서도 문제점이 발생하기 시작합니다. 클래스명 선택자가 장황해지고, 이런 긴 클래스명 때문에 마크업이 불필요하게 커지며, 재사용하려고 할 때마다 모든 UI 컴포넌트를 명시적으로 확장해야만 했습니다.

 또한 SASS와 BEM도 고치지 못했던 몇 가지 문제들은 언어 로직 상에 진정한 캡슐화(encapsulation : 객체의 속성과 행위를 하나로 묶고 실제 구현 내용 일부를 외부에 감추어 은닉하는 개념)의 개념이 없다는 것이었고, 이로 인해 개발자들이 유일한 클래스명을 선택하는 것에 의존할 수밖에 없었습니다.

 

애플리케이션으로 개발 방향이 진화하면서 컴포넌트 단위의 개발은 캡슐화의 중요성을 불러왔습니다. 하지만 CSS는 컴포넌트 기반의 방식을 위해 만들어진 적이 한 번도 없었습니다. 결국 CSS도 컴포넌트 영역으로 불러들이기 위해서 CSS-in-JS가 탄생해서 이 문제를 정확하게 해결합니다.

 CSS-in-JS에는 대표적으로 Styled-Component가 있습니다.

 Styled-Component는 기능적(Functional) 혹은 상태를 가진 컴포넌트들로부터 UI를 완전히 분리해 사용할 수 있는 아주 단순한 패턴을 제공합니다.