primary 버튼 하나에는 클래스가 열 개쯤 필요합니다. 버튼마다 그 열 개를 적으면 조금씩 어긋나고, 모양을 바꾸려면 모든 사본을 고쳐야 합니다. recipe는 그 모양에 한 번 이름을 붙이고, 모든 버튼이 그 이름으로 가져다 쓰게 합니다.

기술적으로 recipe는 tailwind-variants 기반의 변형 팩토리이고, 토큰 계층과 컴포넌트 사이에 있습니다. 계층마다 질문 하나에 답하고, 바로 아래 계층만 압니다:

akanjs/ui는 서버에서도 안전한 모듈에서 buttonRecipe, badgeRecipe, inputRecipe를 제공하고, Button, Badge, Input 컴포넌트도 안에서 같은 recipe를 씁니다. 그래서 recipe로 꾸민 raw 엘리먼트는 컴포넌트와 똑같이 보입니다.

첫 번째 인자로 variant를, 두 번째 인자로 추가 클래스를 넘깁니다. recipe가 tailwind-merge로 알아서 합쳐 주므로 cn()으로 감쌀 필요가 없습니다:

모든 variant 클래스는 시맨틱 토큰(bg-primary, text-success-foreground …)이라서, 어떤 값이든 자동으로 테마를 따라갑니다.

앱에는 프레임워크가 모르는 반복 표면이 있습니다. 그라디언트 히어로, 아이콘 타일, 챗 버블 같은 것입니다. 같은 클래스 문자열을 곳곳에 인라인하지 말고, 각각에 앱 recipe를 만드세요:

그러면 페이지는 클래스 문자열 반복을 멈추고 데이터에서 variant를 읽습니다:

클래스 묶음이 재사용되거나, 조건에 따라 조합되거나, 서버 컴포넌트에서 필요할 때 recipe가 제값을 합니다. 일회성 클래스는 인라인으로 두세요. 내 경우를 왼쪽 열에서 찾아보세요:

앱의 한 구역만 모양이 달라야 할 때가 있습니다. 네온 스타일의 관리자 구역처럼요. 그래도 컴포넌트의 동작은 그대로여야 합니다. recipe override는 모양만 바꾸고 나머지는 건드리지 않습니다.

라우트의 _overrides.tsx는 recipe 슬롯(button, badge, input)을 교체할 수 있습니다. 그 recipe를 쓰는 프레임워크 클라이언트 컴포넌트는 라우트 서브트리 전체에서 새 모양이 되지만, 동작(async 상태, 포커스 트랩, a11y)은 프레임워크 그대로입니다. 바뀌는 것은 className 팩토리뿐입니다.

먼저, 교체할 recipe와 같은 variant 표면을 가진 recipe를 씁니다:

그다음 그 구역의 _overrides.tsx에서 슬롯에 연결합니다. 그 아래 화면 코드는 한 줄도 바뀌지 않습니다:

커스터마이징은 화면마다가 아니라 디자인 시스템을 셋업할 때 한 번 결정합니다. 디자인 스펙을 /lab 카탈로그와 한 번 대조한 뒤, 다른 점마다 아래 질문에 넣어 보세요.