Code States 39일차 - React 컴포넌트 디자인

컴포넌트 단위로 개발하기

Component-Driven Development (CDD)

컴포넌트를 더 나은 방법으로 만들기 : 작은 구성 요소부터

최근 몇 년 동안 웹용 프론트엔드 UI(User Interface) 개발의 가장 큰 추세는 component이다.

React 라이브러리가 첫 번재는 아니지만 대부분 잘 지정된 구성요소에서 UI를 구축하기 위한 패턴을 설정했다.

물론 잘 지정된 역할을 수행하는 더 작은 조각으로 만들어지 소프트웨어를 향한 추세는 새로운 것이 아니다. 

 

Component-Driven Development (CDD)란 무엇일까?

구성 요소를 중심으로 빌드 프로세스를 고정하는 개발 방법론이다. 구성 요소 수준에서 시작하여 페이지 또는 화면 수준에서 끝나는 '아래에서 위로' UI를 구축하는 프로세스이다.

 

CDD의 장점

그렇다면 고정된 일련의 상태에서 한 번에 하나의 구성 요소를 작하는 것이 중요한 이유는 무엇일까?

• Focus develpment(집중 개발) : 전체 앱을 특정 상태로 조작하여 단일 구성 요소에서 작업하는 것은 고통스럽고 힘든 일이다. 특정 상태는 개발 중인 전체 앱 컨텍스트 내에서 달성하기 어렵거나 불가능할 수 있다.
• Increase UI coverage(UI 적용 범위 늘리기) : 모든 관련 상태를 열거하면 누락된 항목이 없고 구성 요소가 가능한 모든 시나리오에서 작동한다고 확신할 수 있다.
• Target feddback(대상 피드백) : 탐색기에서 찾는 것은 동료가 새 구성요소나 변경된 구성 요소를 검토하는 훨씬 쉬운 방법이다. 한 번에 하나의 구성 요소에 초점을 맞추면 훨씬 더 정밀하게 커뮤니케이션(특히 설계와 개발 사이)이 가능하다.
• Build a component library(구성 요소 라이브러리 구축) : 앱 및 조직 내에서 구성 요소 재사용을 강화한다.
• Parallelize development(개발 병렬화) : 한 번에 하나의 구성 요소를 작업하면 '화면' 수준에서는 불가능한 방식으로 다른 팀 구성원 간에 작업을 공유할 수 있다.
• Test visually(시각적으로 테스트) : 구성 요소 탐색기를 사용하면 자동화된 테스트를 종종 거부하는 영역(UI)에서 기존의 자동화된 테스트와 유사한 '시각적' 테스트 클래스를 사용할 수 있다. 특히, TDD와 동일한 이점을 갖지만 UI 영역에서 'Visual TDD'의 형태를 허용한다.

컴포넌트 UI 개발을 위한 Storybook

Component Driven Development가 트레드로 자리 잡게 되면서 이를 지원하는 도구 중 하나인 Component Explorer(컴포넌트 탐색기)가 등장했다. Component Explorer에는 많은 UI 개발도구가 다양하게 있는데 그 중 하나가 Storybook이다.

 

Storybook이 무엇일까?

UI 개발 즉, Component Driven Development를 하기 위한 도구이다. 각각의 컴포넌트들을 따로 볼 수 있게 구성해주어 한 번에 하나의 컴포넌트에서 작업할 수 있다. 복잡한 개발 스택을 시작하거나, 특정 데이터를 데이터베이스로 강제 이동하거나, 애플리케이션 탐색할 필요 없이 전체 UI를 한눈에 보고 개발할 수 있다.

Storybook은 재사용성을 확대하기 위해 컴포넌트를 문서화하고, 자동으로 컴포넌트를 시각화하여 시뮬레이션할 수 있는 다양한 테스트 상태를 확인할 수 있다. 이를 통해 버그를 사전에 방지할 수 있도록 도와준다. 또한 테스트 및 개발 속도를 향상시키는 장점이 있으며, 애플리케이션 또한 의존성을 걱정하지 않고 빌드할 수 있다.

 

Storybook과 같은 UI 개발 도구를 왜 사용할까?

Storybook은 기본적으로 독립적인 개발환경에서 실행된다. 개발자는 애플리케이션의 다양한 상황에 구애받지 않고 UI 컴포넌트를 집중적으로 개발할 수 있다. 개발자들을 위해 문서화(documentation)를 하여 UI 라이브러리로써 사용하거나, 외부 공개용 디자인 시스템(Design System)을 개발하기 위한 기본 플랫폼으로 사용할 수 있다.

 

Storybook에서 지원하는 주요기능

• UI 컴포넌트들을 카탈로그화
• 컴포넌트 변화를 Stories로 저장
• 핫 모듈 재 로딩과 같은 개발 툴 경험을 제공
• 리액트를 포함한 다양한 뷰 레이어 지원

Storybook 설치 및 세팅 방법

은 공식문서를 통해 나중에 해보겠다.

---

구조적인 CSS 작성 방법의 발전

구조화된 CSS가 필요하게 된 이유

프로젝트의 규모나 복잡도가 점점 커지고 함께 작업해야할 팀원 수도 많아짐에 따라 CSS를 작성하는 일관된 패턴이 없다는 것은 개발자들에게 가장 큰 걸림돌이 되었다. 또한 모바일이나 태블릿을 비롯한 다양한 디바이스들의 등장으로 웹 사이트들이 다양한 디스플레이를 커버해야 하기 때문에 CSS는 더 복잡해지게 되었다. 따라서 CSS 작업을 효율적으로 하기 위해 구조화된 CSS의 필요성이 대두되었고, CSS를 구조화하는 방법에 대한 연구가 필요해졌다.

 

CSS 구조화를 위한 다양한 시도

이러한 문제점들을 해결하기 위해 CSS 전처리기(CSS Preprocessor)라는 개념이 등장했다. CSS 전처리기란 CSS가 구조적으로 작성될 수 있게 도움을 주는 도구이다. CSS 문서를 작성할 때는 많은 반복적인 작업을 요구하고 번거로운 작업 역시 포함이 되어 있다. 그뿐만 아니라 CSS 문서의 양이 많아져서 유리관리에 많은 영향을 끼친다. 이런 CSS의 문제점들을 프로그래밍 개념(변수, 함수, 상속 등)을 활용하여 해결할 수 있다. 하지만 CSS 전처리기 자체만으로 웹 서버가 인지하지 못하기 때문에 각 CSS 전처리기에 맞는 Compiler를 사용해야 하고 컴파일을 하게 되면 실제로 우리가 사용하는 CSS 문서로 변환이 된다. 이를 통해 CSS 파일들을 잘 구조화할 수 있게 되었고, 최소한 CSS 파일을 몇 개의 작은 파일로 분리할 수 있는 방법이 생겼다.

 

SASS

CSS 전처리기 중에서 가장 유명한 SASS는 Syntactically Awesome Style Sheets의 약자로 CSS를 확장해 주는 스크립팅 언어이다. 즉, CSS를 만들어주는 언어로서 자바스크립트처럼 특정 속성의 값을 변수로 선언하여 필요한 곳에서 변수를 적용할 수 있고, 반복되는 코드를 한번의 선언으로 여러 곳에서 재사용할 수 있도록 해주는 등의 기능을 가졌다. 그래서 SASS는 SCSS 코드를 읽어서 전처리한 다음 컴파일해서 전역 CSS 번들 파일을 만들어 주는 전처리기의 역할을 한다.

하지만 SASS가 'CSS의 구조화'를 해결해 주는 것의 장점보다 다른 문제들을 더 많이 만들어낸다. 결국 전처리기 내부에서 어떤 작업을 하는지 알지 못한채, 스타일이 겹치는 문제를 해결하기 위해 단순히 계층 구조를 만들어 내는 것에 의지했고, 그 결과 컴파일된 CSS의 용량이 어마어마하게 커지게 됐다.

이런 문제를 보완하기 위해 BEM, OOCSS, SMACSS 같은 CSS 방법론이 대두되었다. 각각의 장단점이 있으나 결국 같은 지향점을 가지고 있다.

방법론의 공통 지향점

• 코드의 재사용
• 코드의 간결화(유지보스 용이)
• 코드의 확장성
• 코드의 에측성(클래스 명으로 의미 예측)

이런 CSS 방법론들은 함꼐 작업하는 상황에서 규칙으로 정해두는 것은 매주 중요하다.

 

BEM

BEM이란 Block, Element, Modifier로 구분하여 클래스명을 작성하는 방법이다. Block, Element, Modifier은 각각 --와 __로 구분한다. 클래스명은 BEM 방식의 이름을 여러 번 반복하여 재사용할 수 있도록 하며 HTML / CSS / SASS 파일에서도 더 일관된 코딩 구조를 만들어 준다.

하지만 클래스명 선택자가 장황해지고, 이런 긴 클래스명 때문에 마크업이 불필요하게 커지며, 재사용하려고 할 때마다 모든 UI 컴포넌트를 명시적으로 확장해야한다. 또한 SASS와 BEM도 고치지 못했던 몇 가지 문제들은 언어 로직상에 진정한 캡슐화(encapsulation : 객체의 속성과 행위를 하나로 묶고 실제 구현 내용 일부를 외부에 감추어 은닉하는 개념)의 개념이 없다는 것이고, 개발자들이 유일한 클래스명을 선택하는 것에 의존할 수 밖에 없다.

 

Styled-Component

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

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

 

	특징	장점	단점
CSS	기본적인 스타일링 방법	-	일관된 패턴을 갖기 어려움 !important의 남용
SASS (preprocessor)	프로그래밍 방법론을 도입하여 컴파일된 CSS를 만들어내는 전처리기	변수/함수/상속 개념을 활용하여 재사용 가능 CSS의 구조화	전처리 과정이 필요 디버깅의 어려움이 있음 컴파일한 CSS 파일이 거대해짐
BEM	CSS 클래스명 작성에 일관된 패턴을 강제하는 방법론	네이밍으로 문제 해결, 전처리 과정 불필요	선택자의 이름이 장황하고, 클래스 목록이 너무 많아짐
Styled-Component (CSS-in-JS)	컴포넌트 기반으로 CSS를 작성할 수 있게 도와주는 라이브러리	CSS를 컴포넌트 안으로 캡슐화, 네이밍이나 최적화를 신경 쓸 필요가 없음	빠른 페이지 로드에 불리함

---

컴포넌트 기반 CSS 작성에 적합한 Styled-Component

styled-components

Styled-Component는 React의 컴포넌트 기반 개발 환경에서 스타일링을 위한 CSS의 성능 향상을 위해 탄생했다. Styled-Component를 사용하면 기존 CSS 문법으로도 스타일 속성이 추가된 React 컴포넌트를 만들 수 있다.

 

Styled-Component의 특징

• Automatic critical CSS
  Styled-Component는 화면에 어떤 컴포넌트가 렌더링 되었는지 추적해서 해당하는 컴포넌트에 대한 스타일을 자동으로 삽입한다. 따라서 코드를 적절히 분배해 놓으면 사용자가 어플리케이션을 사용할 때 최소한의 코드만으로 화면에 띄워지도록 할 수 있다.
• No class name bugs
  Styled-Component는 스스로 유니크한 className을 생성한다. 이는 className의 중복이나 오타로 인한 버그를 줄인다.
• Easier deletion of CSS
  모든 스타일 속성이 특정 컴포넌트와 연결되어 있기 때문에 더 이상 사용하지 않는 컴포넌트를 삭제할 경우 스타일 속성도 함께 삭제된다.
• Simple dynamic styling
  className을 수동으로 관리할 필요 없이 React의 props나 전역 속성을 기반으로 컴포넌트에 스타일 속성을 부여하기 때문에 간단하고 직관적이다.
• Painless maintenance
  컴포넌트에 스타일을 상속하는 속성을 찾아 다른 CSS 파일들을 검색하지 않아도 되기 때문에 코드의 크기가 커지더라도 유지보수가 어렵지 않다.
• Automatic vendor prefixing
  개별 컴포넌트마다 기존의 CSS를 이용하여 스타일 속성을 정의하면 될 뿐이다. 이외의 것들은 Styled-Component가 알아서 처리해 준다.