Tailwind شیوه ساختن UI را برای من عوض کرد، نه سلیقه بصری را

سال‌ها CSS را جدی نوشتم. هنوز هم جدی می‌نویسم. چیزی که در پروژه متوسط به بالا خسته‌ام می‌کرد خودِ زبان نبود. آبشار و اسم کلاس بود. برای یک تغییر padding باید حدس می‌زدی کدام قاعده دیرتر آمده، کدام والد specificity را بالا برده، و کدام `!important` از سه سال پیش هنوز آن‌جاست.

Tailwind این دعوا را برای من کوچک کرد. نه چون «مدرن» است. چون تصمیم بصری را کنار همان قطعه‌ای گذاشت که رندر می‌شود، و مقیاس فاصله و رنگ را از قبل محدود کرد. این نوشته درباره همان تجربه است، با جاهایی که این مدل را خراب می‌کنیم.

چه چیزی واقعاً کند بود

نام‌گذاری جزئی از طراحی شده بود و نباید می‌شد. BEM و بقیه روش‌ها نظم می‌دهند، به شرطی که تیم واقعاً به آن پایبند بماند. در عمل نصف انرژی جلسه می‌رفت روی اینکه کلاس `btn-primary` است یا `button--primary`. ماه بعد یک حالت دیگر اضافه می‌شد و اسم دروغ می‌گفت.

مشکل دوم محل کد بود. استایل در فایل جدا، نشانه‌گذاری در فایل دیگر، و حالت‌ها در ذهن نفر سوم. در کامپوننت React این فاصله بیشتر به چشم می‌آید، چون قطعه از قبل واحد منطقی است. برگشتن به فایل سراسری برای یک حالت hover، حلقه بازخورد را دراز می‌کند.

مشکل سوم مقیاس‌های یتیم بود. یک نفر `18px` می‌گذاشت، یکی `1.125rem`، یکی `padding: 14px 22px`. هیچ‌کدام غلط مطلق نیست. مجموعه که بزرگ شود، صفحه ناهماهنگ است بدون اینکه یک باگ واحد داشته باشی.

کاربردی یعنی چه، بدون شعار

کلاس کاربردی یک کار می‌کند: رنگ متن، فاصله، شعاع، حالت hover. صفحه را با کنار هم گذاشتن همین کارها می‌سازی. به‌جای اختراع اسم برای هر ترکیب، از واژه‌ای استفاده می‌کنی که معنی‌اش در خود کلاس است.

این با Bootstrap فرق دارد. آنجا بیشتر وقت‌ها کامپوننت آماده می‌گیری و بعد با override می‌جنگی تا شبیه برند شود. Tailwind پیش‌فرض بصری کمتری تحمیل می‌کند. مواد خام می‌دهد. اگر توکن برند را در تنظیم تم نگذاری، مواد خامش بوی پیش‌فرض خودش را می‌دهد و همه‌چیز خاکستری آشنا می‌شود. پس «بدون نظر» بودن کامل نیست. نظرش در مقیاس‌هاست، نه در شکل کارت.

اولین بار که این مدل برای من جا افتاد، یک داشبورد کوچک بود که قبلاً به‌خاطر ترس از CSS کهنه عقب می‌افتاد. سرعت از معجزه کلاس نیامد. از این آمد که بین فایل‌ها نمی‌پریدم و برای هر حالت جدید اسم تازه اختراع نمی‌کردم.

محدودیت، ویژگی است

پالت و گام فاصله اگر واقعاً محدود باشد، طراح و برنامه‌نویس کمتر رنگ «تقریباً همان آبی» می‌سازند. این را باید در `theme` قفل کنی. اگر هر جا `bg-[#1a73e8]` بگذاری، محدودیت را دور زده‌ای و فقط املای خاصیت را طولانی کرده‌ای.

برای محصول، توکن معنی‌دار بهتر از عدد خام در همه‌جا است. `bg-primary` که به رنگ برند نگاشت شده، از تکرار `bg-blue-600` در چهل فایل سالم‌تر است. آبی بودن جزئیات پیاده‌سازی است. primary بودن تصمیم محصول است. Tailwind این نگاشت را ممکن می‌کند؛ مجبورت نمی‌کند.

حالت تیره را از اول روی همان توکن‌ها بگذار، نه به‌صورت کلاس جدا که نصف کامپوننت‌ها یادشان می‌رود. اگر طراحی حالت تیره نداری، کلاس‌های دلبخواهی `dark:` پراکنده بعداً بدهی فنی است.

رشته بلند کلاس را با کامپوننت جمع کن، نه با @apply همه‌جا

اعتراض آشنا این است که نشانه‌گذاری زشت می‌شود. اگر هر دکمه ده کلاس تکراری دارد، اعتراض درست است. جوابش برگشتن به CSS سراسری برای همه‌چیز نیست. جوابش کامپوننت است. `Button` با variantهای `primary` و `ghost` همان کلاس‌ها را یک‌بار مالک می‌شود. صفحه مصرف‌کننده اسم قصد را می‌بیند، نه فهرست utility.

`@apply` برای بدنه کامپوننت‌های پایه گاهی خوانا است. اگر همه‌جا به‌کارش ببری، دوباره لایه نام‌گذاری ساخته‌ای، فقط با نحو دیگر، و جستجوی «این استایل از کجا می‌آید» سخت‌تر می‌شود. من `@apply` را برای استثناء کم نگه می‌دارم، نه به‌عنوان معماری.

کلاس شرطی را با یک کمک‌کننده کوچک مثل ترکیب کلاس‌ها مدیریت کن تا رشته‌های قالب تو در تو نسازی. شرط بصری پیچیده یعنی variant کم داری، نه اینکه به ternaries بیشتری نیاز باشد.

چه چیزی را Tailwind حل نمی‌کند

سلسله‌مراتب تایپ، فاصله‌های بخش، و حس برند هنوز کار طراحی است. کلاس کاربردی جلوی سلیقه ضعیف را نمی‌گیرد. فقط اعمال سلیقه را محلی می‌کند.

چیدمان خیلی خاص، انیمیشن زمان‌بندی‌شده، و چاپ، گاهی CSS معمولی روشن‌تر است. اصرار که همه‌چیز utility باشد، کد را مذهبی می‌کند. یک فایل CSS کنار همان قطعه، وقتی کلیدها واقعاً سفارشی‌اند، شکست نیست.

همچنین Tailwind جایگزین سیستم کامپوننت نیست. بدون قرارداد دکمه، ورودی، و سطح‌ها، هر صفحه ترکیب تازه‌ای از کلاس‌ها می‌شود که همه‌شان «درست»اند و محصول یکدست نیست. این را در نوشته طراحی با shadcn/ui جدا باز کرده‌ام. اینجا همین قدر: utility لایه بیان است، نه لایه محصول.

نسخه و پیکربندی را مثل بقیه وابسته‌ها جدی بگیر. ارتقای عمده Tailwind گاهی نام کلاس را عوض می‌کند. اگر رشته کلاس در صدها فایل پخش باشد و کامپوننت پایه نداشته باشی، ارتقا کند می‌شود. این خودش دلیلی است که تکرار را داخل قطعه جمع کنی.

عادت‌هایی که برای من ماند

استایل حالت را کنار نشانه‌گذاری همان حالت می‌نویسم. توکن را در تم تعریف می‌کنم و از رنگ خام فرار می‌کنم. کامپوننت تعاملی را زود استخراج می‌کنم، ولی هر div را کامپوننت نمی‌کنم. و وقتی specificity دوباره وسوسه می‌کند، به‌جای جنگ آبشار، سؤال می‌کنم این استایل چرا دو مالک دارد.

اگر از CSS کلاسیک می‌آیی، هفته اول حس می‌کنی داری تقلب می‌کنی. این حس از آموزشی می‌آید که جدایی محتوا از نمایش را مطلق کرده بود. در کامپوننت، نمایش و ساختار از قبل همسایه‌اند. Tailwind این همسایگی را به رسمیت می‌شناسد. بقیه کار هنوز با تو است: چه چیزی را تکرار کنی، چه چیزی را نام بگذاری، و چه چیزی را اصلاً نسازی.

پرسش‌های کوتاه

برای یک صفحه ساده اضافه نیست؟ اگر پروژه همان یک صفحه می‌ماند، شاید CSS معمولی کوتاه‌تر باشد. اگر قرار است کامپوننت و حالت زیاد شود، زودتر تصمیم را بگیر.

تیم طراحی باید Tailwind یاد بگیرد؟ باید مقیاس و توکن را بشناسد. نوشتن کلاس در پروداکشن وظیفه طراح نیست، مگر اینکه خودتان این مرز را طور دیگری بسته باشید.

می‌شود تدریجی وارد کدبیس قدیمی کرد؟ بله. پیشوند یا محدوده مشخص، و مرز فایل به فایل. مهاجرت بزرگ یک‌جا معمولاً هم استایل را می‌شکند هم انرژی را.