Atomic CSS-in-JS 글 정리

다음글을 정리함 https://sebastienlorber.com/atomic-css-in-js

요약

• 요즘 atomic css-in-js란 새로운 트렌드가 생기는 중이다.
• atomic css-in-js란 atomic css와 css-in-js로 서로 장점만 합친 방법이다.
• atomic css란 css class를 극도로 uitlity 또는 functional하게 만드는 방법이다. tailwind를 생각하면 된다.
• 스타일시트가 작아지고, 마크업과 스티일링을 동시에 할 시 있다는 장점이 있다.
• 반변 클래스명을 공부해야되고, 일관된 클래스명을 생각해야 된다.
• 이걸 css-in-js로 자동화시킨 것이 atomic css-in-js이다.
• 클래스명을 생각할 필요없다. 기존 컴포넌트 만들 듯이 작성하면 알아서 atmoic하게 클래스를 분리시킨다.
• 현재 트위터는 리액트 네이트브 웹, 페이스북은 스타일엑스란 라이브러리를 사용 중
• 페북은 이것으로 413 -> 73로 줄였다. 다크모드를 추가했음에도 불구하고
• 앞으로 새로운 트렌드로 떠오를 것 같다.

개요만 번역

최근 페이스북과 트위터의 프로덕션 배포물들을 보면, atmoic CSS-in-JS라는 새로운 트랜드가 천천히 성장하고 있다고 생각한다.

이 포스트에선, atomic CSS가 무엇인지 확인하고, TailwindwCSS 같은 기능적/유용성-우선 CSS(functinal/utility-first)를 살펴본 다음,

With recent production deployments from Facebook and Twitter, I think a new trend is slowly growing: atomic CSS-in-JS. 리액트의 큰손들의 코드베이스에서 어떻게 채택하고 있는지 알아볼 것이다.

난 이 주제에 전문가는 아니라서, 장단점에 대한 너무 깊은 지식은 기대하지 말아달라. atomic-css-in-js에 대한 생각을 너에게 알려주고 싶을 뿐이다.

주의 : Atmoic CSS는 Atmoic Design과 전혀 관련없음

atomic css란 무엇인가?

BEM, OOCSS... 등등 여러 방법론들이 있다.

<button class="button button--state-danger">
    Danger button
</button>

요즘 유틸우선 콘셉인 Tailwindw CSS가 있고, Functinal css인 Tachyon이 있다.

<button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
  Button
</button>

유틸리티 클래스들의 스타일시트의 뭉치들이 있다면, 너무 길어진다.
아토믹 css는 유틸 우선 css의 극단과 같다, 모든 css 클래스는 하나의 고유한 css 규칙을 가지고 있다.
처음에 아토믹 css는 야후의 Thierry Koblentz에 의해서 사용되었다.

/* Atomic CSS */
.bw-2x {
  border-width: 2px;
}
.bss {
  border-style: solid;
}
.sans {
  font-style: sans-serif;
}
.p-1x {
  padding: 10px;
}


/* Not atomic, because the class contains 2 rules */
.p-1x-sans {
  padding: 10px;
  font-style: sans-serif;
}

템플릿을 수정할 때는, css가 아닌 html을 수정한다. 처음부터 css를 분리하는 것이 "관점의 분리"에 적합하지 않다고 깨달았던 것 같다.

변경된 마크업 방식

• 새로운 컴포넌트를 추가할 때 스타일 시트가 증가되지 않는다.
• 마크업과 스타일이 동시에 개발된다.
• 컴포넌트가 제거될 때 관련 스타일도 동시에 제거된다.

html을 조금 더 커져서 서버 렌더링일 경우 문제가 된다. 하지만 css 파일은 더 이상 중복되지 않는다.

유틸리티/ 원자 css의 한계

몇 가지 문제가 있다.

• 처음에 스타일시트를 작성하고 작업해야 한다.
• 학습 난이도가 있다. 왜냐하면 모든 클래스명 규칙을 알아야하기 때문이다.
• 그러한 규칙이 마음에 들지 않을 수 있다.

Twailwind의 접근 방식

모든 웹 사이트에 고유한 유틸리티 css 파일을 제공하지 않고, 공유 범위와 명명 규칙만 제공
https://tailwindcss.com/docs/configuration/
하지만 여전이 아토믹 스타일에 대한 문제를 가지고 있다.

css-in-js와 비교

Christopher Chedeau는 리액트 생태계에 css-in-js의 아이디어를 널리 퍼뜨림, 그가 말한 css 문제는 아래와 같다.
1. 전역 네임스페이스
2. 의존성
3. 죽은 코드 제거
4. 최소화
5. 공유하는 상수
6. 비결정적 해결 링크
7. 독립성

automatic atomic css-in-js

• 더 이상 클래스 이름 규칙을 만들필요가 없다.
• 일반적인 스타일과 일회용 스타일은 같은 방식으로 처리
• 페이지의 중요한 css를 추출하여 코드 분할
• js에서 css 규칙 삽입 순서 문제를 해결할 수 있는 기회

큰 손들의 후기

• 트위터는 리액트네이티브웹
• 페북은 stylex, 아직 베타임

페북의 이전 버전은 413kb의 css, 현재는 다크모드를 포함해도 74kb임