본문 바로가기
Front-End/Tailwind CSS

Tailwind CSS 에서 혼란을 방지하기 위한 5가지 사례

by sharekim 2024. 5. 19.

출처 :  https://velog.io/@lky5697/5-best-practices-for-preventing-chaos-in-tailwind-css

 

[번역] Tailwind CSS에서 혼란을 방지하기 위한 5가지 모범 사례

원문 : https://evilmartians.com/chronicles/5-best-practices-for-preventing-chaos-in-tailwind-cssTailwind CSS로 작업하는 것은 매우 빠르고 쉽습니다(Tailwind CSS가 널리

velog.io

 

1. 가능한 한 적은 수의 유틸리티 클래스 사용

유틸리티 클래스는 가능한 한 적게 작성하는 것이 좋습니다.

  • pt-4 pb-4를 설정하는 대신 py-4를 사용하면 됩니다. 이는 px, mx 및 my 속성에도 적용됩니다.
  • flex flex-row justify-between 대신 flex justify-between을 사용할 수 있습니다. 이는 flex-row가 CSS에서 flex-direction 속성의 기본값이기 때문입니다. 이와 같은 사용 사례를 더 쉽게 발견할 수 있도록 flex-wrap과 같은 다른 CSS 속성의 기본값을 기억해 두면 유용할 수 있습니다.
  • border border-dotted border-2 border-black border-opacity-50과 같은 긴 클래스 목록을 작성하는 대신 border-dotted border-2 border-black/50을 설정하면 동일한 효과를 얻을 수 있습니다. border-2는 border가 설정되었음을 의미하고 테두리 border-black/50은 RGBA 형식의 축약어를 나타냅니다.

2. 디자인 토큰을 그룹화하고 의미적으로 이름 짓기

module.exports = {
  theme: {
    colors: {
      primary: 'oklch(75% 0.18 154)',
      secondary: 'oklch(40% 0.23 283)',
      error: 'oklch(54% 0.22 29)'
    },
    spacing: {
      'sm': '4px',
      'md': '8px',
      'lg': '12px'
    },
    screens: {
      'sm': '640px',
      'md': '768px'
    },
  },
  //...
}

토큰에 대해 하나의 의미론적 명명 규칙을 유지하면 애플리케이션이 성장함에 따라 필요한 토큰을 더 쉽게 찾고 시스템을 확장할 수 있습니다.

 

예를 들어 오류 상태의 색상을 추가하려면 Figma 파일에서 bright-red 토큰을 복사하여 Tailwind 설정에 붙여넣는 것이 아니라 색상 섹션에 넣고 error와 같은 더 간결한 이름을 지정합니다. 이렇게 하면 시스템의 일관성이 훨씬 더 높아집니다.

 

3. 클래스 순서 유지

<div class="flex h-2 w-1/2 bg-black p-2 font-bold">
  First block with sorted classes
</div>

<div class="flex h-2 w-3 bg-white p-4 font-mono italic">
  Second block with sorted classes
</div>

클래스 순서를 수동으로 유지하려면 많은 시간과 주의가 필요하므로 Tailwind CSS용 공식 Prettier 플러그인을 사용하여 이 작업을 자동화하는 것이 훨씬 더 좋습니다

 

4. 빌드 크기 최소화

번들 크기를 최대한 작게 유지하는 것이 중요합니다. 빌드가 무거우면 페이지 로딩 속도가 느려지고 성능이 저하되며 사용자가 불편을 겪을 수 있기 때문입니다.

 

Tailwind는 수천 개의 유틸리티 클래스를 제공하며, 단일 프로젝트 내에서 모든 클래스를 사용할 가능성은 거의 없습니다. 그렇다면 사용하지 않는 스타일이 프로덕션 빌드에 포함되지 않도록 하려면 어떻게 해야 할까요?

 

Tailwind 버전 3.0 이상을 사용하는 경우 프로젝트에서 JIT(Just-in-Time) 엔진이 기본적으로 활성화되어 있으므로 필요한 만큼 CSS 스타일이 생성되므로 프로덕션 빌드에서 사용하지 않는 스타일을 제거할 필요가 없습니다.

 

하지만 이전 버전의 Tailwind를 사용하는 경우 빌드에 대한 추가 최적화를 수행해야 하는데, 사용하지 않는 CSS를 제거하는 도구인 PurgeCSS를 사용하여 이 작업을 수행할 수 있습니다.

 

5. 스타일 덮어쓰기 및 확장 시 불일치 방지

페이지에 사용자 정의 버튼이 있는 컴포넌트를 사용한다고 가정해 보겠습니다.

<Button className="bg-black" />

그리고 몇 가지 기본 스타일이 있는 Button 컴포넌트가 있습니다.

export const Button = () => {
  return <button className="bg-white">Test button</button>
}

이 경우 버튼은 흰색으로 유지됩니다. Tailwind는 스타일을 자동으로 덮어쓰지 않고 검은색을 적용하므로 Button 컴포넌트에서 이를 지정해야 합니다.

export const Button = ({ className = "bg-white" }) => {
  return <button className={className}>Test button</button>
}

Tailwind의 이러한 측면이 본질적으로 잘못된 것은 아니지만, 많은 스타일을 덮어쓰거나 확장하여 일부 모양을 커스터마이징하려는 경우 매번 프롭을 통해 클래스를 전달해야 하는 번거로움이 있을 수 있습니다.

게다가 이 접근 방식에는 단점이 하나 더 있는데, 프롭을 통해 유틸리티를 받아들이면 일관된 컴포넌트 뷰를 보장하기가 더 어려워질 수 있다는 점입니다. 이 접근 방식은 앱 전체에서 동일한 컴포넌트에 대해 아무 유틸리티나 조합하여 사용하도록 권장하므로 시각적 일관성이 부족할 수 있습니다.

그렇다면 어떻게 하면 될까요?

프롭을 통해 임의의 유틸리티 클래스를 전달할 수 있도록 허용하는 대신 미리 정의된 변형 집합을 정의합니다.

const BUTTON_VARIANTS = {
  primary: "bg-blue-500 hover:bg-blue-600 text-white",
  secondary: "bg-gray-500 hover:bg-gray-600 text-white",
  danger: "bg-red-500 hover:bg-red-600 text-white"
};

그런 다음 Button 컴포넌트를 변경하여 variant 프롭을 사용할 수 있도록 합니다.

댓글

티스토리툴바