Applying Atomic css?

[sungik-choi]

From #1975

Miscellaneous 🤔

FYI. @yangwooseong

• 지금 당장 해결할 문제는 아니지만, 작업하다보니 CSS Modules가 가지는 스타일 중복에 대한 문제가 느껴집니다. 사실 용량을 신경쓰지 않는다면 문제될 부분은 없지만, 신경쓰지 않을 수가 없는 문제같아요. SCSS 작업을 완료한 이후 CSS 최종 사이즈가 압축 이전 100KB 정도가 되니 마냥 작은 사이즈는 아닙니다.
• 중복을 제거하자면 atomic class를 사용해야할텐데, 이번 마이그레이션 과정에서도 atomic class 비슷하게 구현한 부분들이 있으나(e.g. elevation.module.scss) 이를 다른 컴포넌트에서 사용하는 경험이 좋지 않고(모듈 import 후, className에 적용해야함) 스타일링 방식이 일관적이지 않아서 전역적으로 사용하지 않았어요.
• atomic class를 구현하는 로직에서도 token 값을 재선언해야하는 문제가 있어요. token 데이터를 기반으로 atomic class를 바로 생성해주는 게 가장 좋아보이는데 말이죠. 예를 들어 아래와 같은 부분입니다.

$radiuses: 2, 3, 4, 6, 8, 12, 16, 20, 32, 44, 42-p; // <-- 토큰 값이 변경되면 수동으로 변경해줘야해요

@each $radius in $radiuses {
  :where(.radius-#{$radius}) {
    border-radius: var(--radius-#{$radius});
  }
}

• Remove the CSS-in-JS library #1106 에서 CSS modules를 선택했던 이유가 외부 의존성을 제거하기 위해서였기에 기대치를 충분히 잘 충족하는 선택이었다고 생각합니다. 하지만 더 나아가서 추후 css 사이즈 등을 더 신경써야한다면 atomic class 기반의 스타일 시스템(e.g. tailwind, panda css, stylex)을 내부적으로만 사용하는 걸 고려해봐야할 수도 있을 거 같아요.
• 다행히 이번 마이그레이션을 통해 특정 라이브러리의 의존성을 제거했기 때문에, 언제가 될진 모르겠지만 그 때가 온다면, 그 때는 Breaking change 없이 점진적으로 마이그레이션을 잘 진행할 수 있을 거 같아요.