최근 시작한 프로젝트에서는 공통 UI 컴포넌트를 정의하는 일이 중요해보였습니다.
스타일이 정의된 클래스 이름이 여러 개 검색되는 현상을 확인하고 ... 조금 당황했습니다. UI관리가 필요하다고 느꼈습니다.
함께 작업하시는 분의 생각과 가치관도 운이 좋게 저와 같았습니다.
🤗 그래서 저희는 UX Engineer의 Vision과 Role을 이해하고 프론트엔드 개발자에게 협의할 자료를 만들기 시작했습니다.
storybook, framer 와 같은 툴 부터 MUI, attlassian, toss 등 우수한 사례의 레퍼런스를 확인했고,
현재 프로젝트 단계와 저희가 처리할 수 있는 업무량을 고려하여 다음과 같이 작업 전략을 수립했습니다.
1 - 스타일 코드 컨벤션
어떻게 스타일 속성을 관리할 것인가?
작성 배경
css 의 가장 큰 특징은 사고적으로 에러인 상황을 걸러내지 못한다는 점입니다.
😣 왜 디버깅을 할 수 없을까용? -> 😐 에러가 아니니까요...
예를 들어.btn-close라는 스타일 속성이<button className="btn-close" />에 적용되어 있다는 것을 보장할 수가 없습니다.
만약.btn-clese<button className="btn-closee" />와 같은 오타에도 에러가 발생하지 않습니다.
- 렌더링 과정 이해하기 🐧🐧 Naver d2 브라우저는 어떻게 동작하는가?
브라우저가 렌더트리를 만들 때는 html과 css의 토큰화 과정이 병렬로 진행되며 css는 기본적으로 자유 문법이다.
- 렌더트리 생성(형상구축) 과정을 간단하게 보면
css - css선택자 token tree(cssom)생성
html - 아이디/클래스 네임에 해당하는 css 선택자 찾기 -> stylesheet cascade에 따라서 해당 선택자가 없으면 브라우저 선언(user agent style)을 따름
- 따라서 html-아이디/클래스 네임에 해당하는 css 클래스 없을 시 에러가 아님.
따라서 사고적으로 에러인 상황을 잡아내기 위해 다양한 방법들이 고려되고 있으며,
현 프로젝트에서는 scss와 style module, typescript declare를 적용하여 선택자가 없는 상황을 방지하고 있습니다.
하지만 다음과 같은 상황은 어떨까요?
header 외부의 버튼은 빨간색이 아닙니다. 이런 상황은 style module, typescript declare로도 잡아낼 수 없습니다. 작업자의 꼼꼼함에 의지해야하는 상황입니다. 그래도 위와 같은 상황은 심각하지 않습니다.
프로젝트가 커진다면 어떻게 될까요?
close버튼이 여러 군데에서 사용된다면?- 디자인은 각각 다르게 가져가야 한다면?
개발자가 스타일 속성을 일일이 확인하는 건 힘든 일입니다. 특히 처음부터 혼자 개발한것이 아닌 이상 고려하기 어렵습니다.
UI가 복잡해진다면 어떨까요?
스타일 값만 보고도 화면이 그려지고 어떤 태그 구조를 가져야 하는지 바로 알기 어렵습니다.
종속성 (css에서는 specific하게 선택한다고 합니다) 이 강해질 수록 더욱 곤란합니다.
그래서 저희는 공통 UI의 스타일 값을 정의하기위해서
서로가 동의할 수 있는 협업 방식과 이를 문서화 할 필요가 있다고 생각했습니다.
문서가 완성되기까지 과정은 다음과 같았습니다.
1. 각자 작업 방식 정리, 레퍼런스 분석
2. 각자 컨벤션 초안 발행 (아이디어를 중심으로)
3. 초안 합치기위한 협의 (3번 진행)
4. 보고
문서 구성은 다음과 같았습니다.
- 의의
- 코드 가독성 작업 (prettier&shortcuts)
- directory 구조
- 선택자, 클래스명
- 공통 UI 스타일
- 레이아웃 구조
- css in js, css in css
...
업무와 병행하면서 만들었기 때문에 약 두 달이상이 소요된거 같습니다.
그래도 만들었습니다 !! 😀
