디자인 시스템에서는 일관성과 이해력이 가장 중요합니다. 좋은 디자인 시스템은 이를 구현하는 코드 구성을 통해 구현의 일관성을 보장합니다. 다음과 같아야 합니다.
Tailwind와 함께 React의 기본 스택을 사용하여 타이포그래피, 색상, 간격에 대한 자체 기본값을 설정하는 것이 앱의 모양과 느낌을 차별화하기 위한 시작점이 아니라는 점을 보여 드리겠습니다. 더 중요한 것은 작성하고 유지 관리해야 하는 코드를 대폭 줄여 체계적이고 일관되며 오류 없는 방식으로 스타일을 구현하는 데 따른 정신적 부담을 줄여준다는 것입니다.
항상 볼 수 있는 주요 비판부터 시작하여 이를 해결하기 위해 사용하는 일련의 구성 단계를 분석하겠습니다.
Tailwind를 사용하면 개발자가 스타일을 쉽게 작성할 수 있어 신속한 프로토타이핑에 적합합니다. 하지만 이러한 용이성이 좋은 디자인이나 확장 가능하고 유지 관리 가능한 디자인 시스템을 보장하지는 않습니다.
Tailwind와 같은 기본값 및 구성이 필요 없는 도구는 구축 시간을 더 많이 만들어 주는 인프라 속도 계층입니다. 하지만 차별화를 위해 디자인 시스템을 사용하는 앱을 확장하는 경우에는 "점심 시간에 무료로 제공되는" 기본 구성에만 의존할 수는 없습니다.
기본 Tailwind 구성을 사용하여 실행하고 구성 요소의 클래스 애플리케이션에 스타일 관리를 푸시하면 결과적으로 디자인 시스템으로 가장하여 구성 요소 전체에 흩어져 있는 추론하기 어려운 클래스가 엉망이 되는 경우가 많습니다.
위는 대표적인 예입니다. 거의 읽을 수 없으며 조작은커녕 이해하는 데 상당한 시간이 걸립니다. 그렇게 시도하면 중복과 오류가 발생하여 앱 전체의 디자인 일관성이 무너질 가능성이 높습니다.
디자인 클래스를 단일 className으로 묶는 것은 쉽습니다. 그러나 그렇게 하는 데는 지식이 쉽지 않습니다.
사용 편의성에는 절충점이 따릅니다. 다른 사람의 기준을 따른다는 것은 그 사람의 노하우에 의존한다는 뜻이다. 이는 유익할 수도 있지만 함정이 될 수도 있습니다. 한발 물러서서 디자인 시스템의 기본 구성이 무엇인지 생각해 보겠습니다.
React with Tailwind의 맥락에서 이러한 요소와 기타 여러 디자인 시스템 요소는 Tailwind 구성에 설정되어 있으며 이를 맞춤설정할 수 있습니다.
{/* 더 예뻐요-무시 */}
const config = { theme: { fontSize: { /* ... */ }, colors: { /* ... */ }, spacing: { /* ... */ }, }, };
작은 텍스트의 올바른 문자 간격을 기억하는 데 어려움을 겪은 적이 있습니까? 한 번 설정하고 잊어버릴 수 있다면 어떨까요?
tailwind.config에서 직접 각 글꼴 크기 튜플에 대한 매개변수로 행간(줄 높이) 및 자간(문자 간격)을 설정할 수 있습니다. 즉, 글꼴 크기 클래스를 사용할 때 행간 또는 추적을 설정할 필요가 없습니다. 작은 텍스트의 글자 간격이 무엇인지 기억할 필요가 없습니다(또는 검색하지 않을 필요도 없습니다).
fontSize: { small: [ "13px", { lineHeight: 1.5, letterSpacing: "0.015em" }, ], base: [ "16px", { lineHeight: 1.5, letterSpacing: 0 }, ], }
이제 text-small을 사용하면 글꼴 크기, 줄 높이 및 문자 간격이 설정됩니다. 핵심 인쇄 튜플을 하나의 클래스에 함께 포함하면 이러한 값의 구현이 코드베이스 전체가 아닌 구성에 집중됩니다. 유지 관리 측면에서 큰 승리를 거두었습니다.
/* 13px/1.5 with 0.015em letter-spacing */
CSS 변수를 사용하여 :root 및 html.dark 범위에서 반응형 색상을 설정할 수 있습니다. 이는 bg-gray-100 dark:bg-gray-800과 같은 두 개의 클래스 대신 bg-canvas와 같은 하나의 클래스를 작성하고 관리한다는 의미입니다.
@import "@radix-ui/colors/gray.css"; @import "@radix-ui/colors/gray-dark.css"; :root { --color-gray-base: var(--gray-1); --color-gray-bg: var(--gray-3); --color-gray-line: var(--gray-4); --color-gray-border: var(--gray-5); --color-gray-solid: var(--gray-10); --color-gray-fill: var(--gray-12); }
여기서 Radix Colors를 사용하고 있기 때문에 .dark 범위가 이미 설정되어 있으므로 설정할 필요가 없습니다. Radix 색상이 마음에 들지 않으면 맞춤설정하거나 다른 라이브러리를 사용하거나 직접 작성할 수 있습니다.
그런 다음 Tailwind 구성에서 CSS 변수를 설정합니다.
colors: { canvas: "var(--color-gray-base)", background: "var(--color-gray-bg)", line: "var(--color-gray-line)", border: "var(--color-gray-border)", solid: "var(--color-gray-solid)", fill: "var(--color-gray-fill-contrast)", }
이제 bg-canvas를 사용하면 밝거나 어두운 모드에서 적절한 색상이 설정됩니다. 코드베이스 전체에서 이러한 중복을 제거하면 색상 관리를 구성 요소의 클래스 구현 전체에 분산시키는 대신 구성에 중앙 집중화합니다. 인지도와 유지 관리 용이성 측면에서 큰 승리를 거두었습니다.
/* sets --gray-1 as #fcfcfc on :root or #111111 on html.dark */
저는 의미론적 이름을 색상과 글꼴 크기에 사용하는 것을 선호합니다. 의미론적 이름 지정은 사용할 의미를 연결하는 강제 기능이기 때문입니다. 그렇게 하면 구현 추측 작업이 제거되고 오류가 줄어듭니다.
일관되지 않은 회색-50, 회색-100 또는 회색-200이 모두 배경에 사용되는 수많은 프로젝트를 보았습니다. 이는 배경이라는 색상을 정의하면 쉽게 해결됩니다.
마찬가지로 어둡고 밝은 텍스트 색상을 채우기 및 단색이라고 하면 이름을 기억하기가 더 쉽습니다. 회색-900과 회색-600이라고 하면 회색-950과 회색-500, 또는 회색-800과 회색-700이 아니라는 점을 구체적으로 기억해야 하기 때문에 더 어렵고 오류가 발생하기 쉽습니다.
하지만 이름을 지정하고 이름에 동의하는 것은 어렵습니다. 제로 구성의 정신으로 Radix Color의 배경, 테두리, 단색 및 채우기 패러다임을 사용하는 것이 좋습니다. 아니면 이 팔레트 의미론입니다.
tailwind.config에서 이를 설정하면 Typescript가 자동 완성을 통해 여러분의 기억을 손쉽게 불러올 것입니다.
Tailwind 테마를 확장하고 직접 작성하지 않는 경우 이미 사용된 스케일 키를 사용하지 마세요. 사용해야 하는 클래스를 실수로 덮어쓸 수도 있습니다.
이전 색상 구성 예에서 --color-gray-base var를 base가 아닌 canvas로 설정한 것을 알 수 있습니다. 기본을 사용한 경우 이 색상 스케일을 텍스트 색상(텍스트 기반)으로 사용하면 텍스트 기반이기도 한 기본 글꼴 크기 기본 값과 충돌하게 됩니다.
이는 Tailwind 구성 맞춤설정의 단점이 아니라 테마 이름 지정의 유산입니다. Tailwind에서 글꼴 크기 또는 색상 클래스를 설정하면 모두 text-*를 사용합니다.1
CSS 변수를 사용하여 간격을 설정할 수도 있습니다.
:root { --height-nav: 80px; --height-tab: 54px; --space-inset: 20px; --container-text-px: 660px; --container-hero-px: 1000px; }
spacing: { em: "1em", /* relate icon size to parent font-size */ nav: "var(--height-nav)", inset: "var(--space-inset)", text: "var(--container-text)", hero: "var(--container-hero)", }
누군가는 이것이 과도한 엔지니어링이라고 주장할 수도 있습니다. 고정 헤더, 스크롤 여백 등과 같은 복잡한 대화형 레이아웃을 계산해야 하는 경우를 제외하면 이 사전 구성 작업을 통해 픽셀까지 간단하고 오류가 발생하지 않습니다.
/* ... */
의미론적 이름 지정을 사용하면 기억하고 사용하기가 쉬워진다는 점에 다시 한 번 유의하세요.
이제 중앙 집중화된 단일 장소에서 이해하고 유지 관리하기 쉬운 방식으로 타이포그래피, 색상 및 간격 토큰을 구성했습니다. 그리고 시스템을 구현하기 위해 많은 클래스를 작성할 필요가 없습니다. 승리. 그리고 이러한 구현 오버헤드를 줄이기 위해 취할 수 있는 추가 조치가 있습니다.
text-lg lg:text-xl xl:text-2xl p-2 md:p-4 lg:p-8을 어디에서나 쓰는 것을 완전히 피할 수 있는 방법이 있다고 말하면 어떻게 될까요?
tailwind.config에서 글꼴 크기 값으로 클램프를 사용하면 반응형 글꼴 크기 클래스 설정을 피할 수 있습니다. 제가 사용하는 간단한 클램프 기능은 다음과 같습니다.
fontSize: { title: [ /* clamp(17px, 14.1429px 0.5714vw, 21px) */ generateClampSize(500, 1200, 17, 21), { lineHeight: 1.5, letterSpacing: "-0.015em" }, ]; }
따라서 text-lg lg:text-xl xl:text-2xl을 작성하는 대신 text-title을 작성하면 됩니다. 다시 한번, 글꼴 크기 응답성을 클램프 값으로 끌어올려 "클래스 구현"의 함정을 다시 피하고 정신적 노력, 오류 및 디버깅 시간을 절약합니다.
명심하세요. 이는 Tailwind를 올바르게 구성하여 text-lg lg:text-xl xl:text-2xlleading-none 추적 전체에서 text-title로 이동했음을 의미합니다. 승리!
/* 17px at 500px, 21px at 1200, fluidly calculated inbetween */ /* …with default line-height and letter-spacing also specified */Heading copy
간격에 대해서도 이 작업을 수행할 수 있습니다. 테마를 확장할 때 기본 간격 척도와 구별하기 위해 이 키 앞에 "동적"을 의미하는 d를 붙입니다.
spacing: { /* lower value is 2/3 of upper value */ d4: generateClampSize(500, 1200, 10.5, 16), d8: generateClampSize(500, 1200, 21, 32), d16: generateClampSize(500, 1200, 43, 64), d24: generateClampSize(500, 1200, 64, 96), d64: generateClampSize(500, 1200, 171, 256), }
이를 통해 py-16 md:py-20 lg:py-24 대신 py-d24를 작성할 수 있습니다. 이는 각 미디어 쿼리에 대해 다양한 웹사이트 버전을 마음속에 담아 두는 부담을 덜어줍니다. 대신 측정이 일관된 관계만큼 중요하지 않은 유동적으로 반응하는 레이아웃을 상상하도록 권장합니다.
/* ... */ /* ... */
잘 만들어진 UI는 다가오는 부주의한 AI 앱에 대한 최후의 방어책입니다. Tailwind를 맞춤설정하면 시간과 골치 아픈 작업을 절약하여 눈 깜짝할 사이에 작동하는 UI를 구축하는 데 필요한 비합리적인 노력에 집중할 수 있는 방법은 다음과 같습니다.
예, 선불 시간 비용이 있습니다. 그러나 이는 코드 감소, 오류 감소, 설계 일관성 향상, 시스템을 실제로 이해하는 팀이라는 측면에서 큰 성과를 거두고 있습니다.
다음: Class Variance Authority를 사용하여 Tailwind에서 가져온 의미 체계 소품으로 방탄 스타일링 API를 만드는 방법을 살펴보겠습니다. 계속 지켜봐 주시기 바랍니다.
이것이 JSX에서 중복된 Tailwind 클래스를 제거하기 위해 tailwind-merge를 사용하는 것을 싫어하는 이유이기도 합니다. 대개 둘 다 필요할 때 text-fontSize를 선호하여 텍스트 색상을 제거하는 경우가 많습니다. 더 많은 개발자가 이 문제를 제기하지 않는다는 사실에 놀랐습니다. ↩
부인 성명: 제공된 모든 리소스는 부분적으로 인터넷에서 가져온 것입니다. 귀하의 저작권이나 기타 권리 및 이익이 침해된 경우 자세한 이유를 설명하고 저작권 또는 권리 및 이익에 대한 증거를 제공한 후 이메일([email protected])로 보내주십시오. 최대한 빨리 처리해 드리겠습니다.
Copyright© 2022 湘ICP备2022001581号-3