// tailwind.config.js
module.exports = {
theme: {
extend: {
colors: {
brand: {
light: '#3fbaeb',
DEFAULT: '#0fa9e6',
dark: '#0c87b8',
}
},
spacing: {
'18': '4.5rem', // Valoare lipsă în Tailwind, dar folosită des în layout
}
}
}
}Salutare. Hai să vorbim despre o chestie care mă zgârie pe ochi în ultima vreme: abuzul de arbitrary values în Tailwind, gen top-[13px] sau bg-[#f3a123]. Am trecut recent printr-un audit pe un proiect cu vreo 42 de componente complexe și am găsit peste 200 de valori de genul ăsta, aruncate complet haotic în cod.
La început, arbitrary values au fost văzute ca o binecuvântare pentru că nu mai trebuia să scrii CSS custom pentru excepții. Dar linia dintre „o mică excepție” și „haos total în UI” e extrem de subțire.
Când e complet OK să folosești arbitrary values
Nu trebuie să devenim extremiști. Clasa arbitrară, de tipul h-[calc(100vh-80px)], își are locul ei bine definit în workflow-ul nostru.
Am avut cazul unui landing page unde aveam nevoie de o înălțime fixă de 540px doar pe rezoluția de desktop, o singură dată pe tot site-ul. Acolo am trântit un lg:h-[540px] fără nicio remușcare.
E complet în regulă să le folosești când:
- Ai o valoare unică pe care nu o vei mai repeta niciodată (un clip-path ciudat, o poziție absolută pentru un glob decorativ).
- Calculezi dinamic ceva cu
calc()direct în clasă. - Lucrezi la un prototip rapid și vrei să vezi cum arată înainte să definitivezi design-ul.
Când devine periculos (Și de ce ai nevoie de Design Tokens)
Problema apare din lene. Decât să deschizi tailwind.config.js ca să adaugi o nuanță nouă de gri trimisă de designer, un dev junior o să trântească text-[#4a4a4a] direct în componentă.
După 6 luni, designerul decide că „brandul se schimbă puțin” și acel gri trebuie să devină #3d3d3d. Succes la căutat și înlocuit prin zeci de fișiere .tsx sau .vue. Ai toate șansele să ratezi jumătate din ele sau să strici alte elemente care foloseau aceeași culoare din alte motive.
Aici intervin token-urile de design. Tot ce înseamnă identitate vizuală – culori, fonturi, umbre, spacing-ul de bază – trebuie să stea în config.
Compromisul sincer: Config-ul uriaș vs Flexibilitatea
Hai să fim realiști, există un trade-off destul de enervant aici.
Dacă încerci să transformi absolut totul în token-uri, fișierul tău tailwind.config.js va deveni un monstru de 1.000 de linii. Vei ajunge să ai token-uri de genul width: { 'tooltip-small': '120px', 'tooltip-large': '240px' } doar pentru că ai vrut să fii „curat”. Asta adaugă o încărcătură cognitivă inutilă. Trebuie să reții denumiri inventate în loc să scrii cod rapid.
Regula mea de aur, pe care am aplicat-o cu succes și am salvat cam 30% din timpul de refactoring la ultimul proiect, este regula de trei:
- Prima dată când apare o dimensiune ciudată în Figma, o scriu ca arbitrary value.
- A doua oară când o văd, o las tot așa, dar încep să fiu atent.
- A treia oară când apare în ecrane diferite, deschid config-ul și o transform în design token.
Voi cum gestionați asta în echipele voastre? Lăsați designerii să facă legea cu valori custom sau îi forțați să se lipească de grid-ul standard Tailwind?