// tailwind.config.js - Cum am structurat token-urile pentru a evita haosul
module.exports = {
theme: {
extend: {
colors: {
brand: {
light: '#3fbaeb',
DEFAULT: '#0fa9e6',
dark: '#0c87b8',
},
},
spacing: {
'13': '3.25rem', // Doar dacă designerul insistă că 13 e număr norocos
}
},
},
}M-am lovit recent de un codebase unde aproape orice padding sau culoare era definită cu arbitrary values. Era un fel de Inline CSS mascat sub sintaxă de Tailwind. E ușor să cazi în capcana asta când ai un deadline strâns și designerul îți livrează ecrane care nu respectă nicio grilă de 4 sau 8 pixeli, dar pe termen lung, e o rețetă sigură pentru un refactoring dureros.
Am pățit-o la un dashboard complex cu peste 60 de componente custom. Designerul era creativ, dar cam haotic la început. Aveam vreo 12 nuanțe de albastru în Figma, toate diferite cu câte un procent la luminozitate. La început, am zis că „e doar pentru butonul ăsta”, așa că am trântit un bg-[#1a2b3c]. După două săptămâni, aveam acel hex code împrăștiat în 15 fișiere. Când s-a decis că brandul trebuie să fie un pic mai „vibrant”, am pierdut o după-amiază întreagă cu search and replace, sperând să nu stric altceva prin cod.
Când să folosești arbitrary values ([...])
Arbitrary values sunt un „escape hatch” excelent, dar trebuie folosite cu măsură. Mie mi se par utile doar în două situații clare. Prima: când ai un element absolut unic, cum ar fi un logo care trebuie poziționat la fix top-[117px] dintr-un motiv care ține de compoziția vizuală a paginii de landing. A doua: când faci un prototip rapid și vrei să vezi cum arată o idee înainte să poluezi tailwind.config.js.
Trade-off-ul e simplu: câștigi 10 secunde acum, dar pierzi predictibilitatea. Dacă ai text-[15px] peste tot, de ce mai folosim Tailwind? Putem scrie direct style tag-uri. La proiectul de care ziceam, am economisit cam 30% din timpul de refactoring ulterior după ce am impus o regulă dură: orice valoare care apare de mai mult de 3 ori devine design token.
Puterea design token-urilor în config
Design token-urile nu sunt doar variabile, sunt limbajul comun cu designul. Când definești theme.extend.colors.brand-primary, nu mai discuți despre hex-uri, ci despre funcționalitate. Am observat că pe termen lung, asta reduce oboseala cognitivă. Nu mai trebuie să verific în Figma dacă albastrul de pe buton e același cu cel de pe iconiță; știu că ambele folosesc token-ul de brand.
Dacă ai un sistem de design serios, config-ul tău ar trebui să fie sursa adevărului. Am avut un caz unde am mapat toate distanțele la o scară fixă de 4px. Chiar dacă designerul mai scăpa un margin-top: 13px, eu puneam mt-3 (12px) sau mt-4 (16px). De cele mai multe ori, nici nu observa diferența de un pixel, dar codul rămânea curat și aliniat la grilă. Asta m-a salvat de la a avea un layout care „tremură” vizual pe rezoluții diferite.
Strategia mea de curățenie
De obicei, încep proiectul destul de permisiv, dar o dată pe săptămână dau un search după -[ în tot folderul src. Dacă văd că se adună prea multe, e semn că sistemul de design are găuri sau eu am devenit leneș.
O chestie care merge bine: dacă ai imagini de background dinamice sau calcule complexe cu calc(), arbitrary values sunt imbatabile. Nu are sens să pui în config ceva ce depinde de contextul runtime sau de un asset extern care se schimbă des. Totuși, pentru culori, font-sizes și spacing, config-ul e sfânt.
În final, regula mea e simplă: arbitrary values sunt pentru excepții, design token-urile sunt pentru reguli. Voi cum procedați când primiți un design care pare că ignoră orice sistem de grid? Faceți push-back la designer sau „mânjiți” codul cu paranteze pătrate?