طراحی دیزاینسیستم با Tailwind و HeroUI بدون هرجومرج کلاسها
از توکن و واریانت تا بستهٔ کامپوننت مشترک؛ چطور Tailwind و HeroUI را به سیستم محصول تبدیل کنیم نه مجموعهٔ utility پراکنده.
علی مرتضوی
بنیانگذار پارادایس کد
دیزاینسیستم قبل از کامپوننت شروع میشود
اگر با Button شروع کنید و توکن نداشته باشید، فقط کتابخانهٔ UI میسازید نه سیستم. اول تصمیمهای بنیادین را قفل کنید: مقیاس فاصله، تایپ، شعاع، سایه، رنگ معنایی (primary/danger/success)، و حالتهای تعامل. Tailwind اینها را بهصورت توکن/تم درمیآورد تا کلاسهای خام در فیچرها پخش نشوند.
HeroUI سرعت پیادهسازی تعاملهای دسترسپذیر را بالا میبرد، اما بدون لایهٔ توکن محصول، هر صفحه pallette خودش را میسازد. سیستم یعنی محدودیت آگاهانه.
توکنها را معنایی کنید نه تزئینی
بهجای `blue-600` در فیچرها، `brand`، `surface`، `muted`، `danger` تعریف کنید. رنگ تزئینی به برند گره میخورد؛ رنگ معنایی به نقش UI. وقتی برند عوض شد، توکن را عوض میکنید نه صدها کلاس.
برای حالت تاریک/روشن یا تم مشتری، همین معناها را map کنید. اگر هر کامپوننت شرط رنگ خودش را دارد، تمپذیری از دست رفته است.
واریانت و ترکیب بهجای کپی کلاس
الگوی `cva`/واریانت برای اندازه، ظاهر و state، تکرار `className` طولانی را کم میکند. API کامپوننت باید کوتاه باشد: `variant`, `size`, `isDisabled`. اگر مصرفکننده باید ده کلاس Tailwind پاس بدهد، encapsulation شکست خورده است.
Escape hatch محدود بگذارید (`className` کنترلشده) اما در review با سؤال «چرا سیستم کافی نبود؟» مواجهش کنید. هر استثنا یا توکن جدید میسازد یا بدهی بصری.
HeroUI را هسته بگیرید، نه پوستهای برای دور زدن
از رفتار دسترسیپذیر آماده—فوکوس، کیبورد، دیالوگ—استفاده کنید و ظاهر را با توکنهای خودتان همراستا کنید. بازنویسی کامل کامپوننت فقط برای سلیقه، هزینه نگهداری را بالا میبرد و آپدیت کتابخانه را سخت میکند.
جایی که HeroUI الگوی محصول را پوشش نمیدهد، primitive بسازید و در داستان دیزاینسیستم ثبت کنید. سیستم زنده با inventory مشخص جلو میرود، نه با کامپوننتهای یتیم در فیچرها.
مستند مصرف برای مهندس و دیزاینر
Storybook یا معادلش باید حالتها، Do/Don't، و فاصلهگذاری را نشان دهد—نه فقط گالری زیبا. برای هر کامپوننت: کی استفاده شود، چه واریانتی پیشفرض است، و چه چیز ممنوع است.
دیزاینر و مهندس باید روی یک زبان نامگذاری باشند. اگر در Figma «Primary / Large» و در کد `variant="solid" size="lg"` است، جدول نگاشت را صریح بنویسید.
حاکمیت تغییر بدون بوروکراسی
تغییر توکن بنیادین باید PR جدا و اسکرینشات مسیرهای کلیدی داشته باشد. تغییر واریانت جدید نیاز به مورد استفادهٔ واقعی دارد، نه «شاید بعداً».
هر فصل یک audit بصری کوتاه انجام دهید: کلاسهای خام پرتکرار را به توکن/کامپوننت برگردانید. این نظافت ارزانتر از بازنویسی UI سال بعد است.
سؤالات متداول
آیا فقط Tailwind بدون کتابخانه UI کافی است؟
برای محصول کوچک بله، اما هزینه دسترسیپذیری و یکنواختی تعامل را خودتان میپردازید. HeroUI آن هزینه را کم میکند اگر توکنمحور مصرف شود.
چقدر به className آزاد اجازه بدهیم؟
کم و کنترلشده. اگر الگوی تکراری شد، واریانت یا توکن جدید بسازید نه کپی کلاس.
دیزاینسیستم را کی شروع کنیم؟
بهمحض وجود بیش از یک سطحکننده یا دو اپ مرتبط. تأخیر یعنی بازپرداخت بدهی بصری با بهره.
دانش و مقالات
نیاز به اجرای همین مفاهیم در محصولتان دارید؟
پارادایس کد از مشاوره تا پیادهسازی کامل کنار شماست.