// tailwind.config.js
module.exports = {
theme: {
extend: {
colors: {
brand: {
primary: '#0f172a',
secondary: '#0284c7',
accent: '#f59e0b',
}
},
spacing: {
'18': '4.5rem', // valoare custom dar standardizată
}
}
}
}Am lucrat recent la un proiect cu vreo 15.000 de utilizatori activi unde echipa de design a decis să schimbe identitatea vizuală. Sună simplu în teorie, dar în practică ne-a luat trei zile de muncă brută doar ca să curățăm CSS-ul. De ce? Pentru că codebase-ul era plin de clase de tipul bg-[#f3a412] sau w-[312px] împrăștiate peste tot prin componente.
Tailwind are această super-putere: arbitrary values (clasele alea scrise cu paranteze pătrate). Sunt geniale când ai nevoie de o chestie rapidă, dar devin un coșmar dacă nu știi când să te oprești.
Când e ok să folosești arbitrary values?
Nu sunt un extremist al design system-ului. Uneori, pragmatismul bate teoria din manuale. Am avut destule cazuri când a trebuit să aliniez o siglă ciudată de la un client pe un header și singura variantă curată a fost un top-[3px].
Iată cazurile unde arbitrary values chiar își au sensul:
- Poziționări unice: Un element absolut care trebuie să stea la fix
right-[17px]din cauza unui asset grafic ciudat. - Grid-uri ultra-specifice: Când ai un layout asimetric pe care nu-l mai folosești nicăieri în aplicație (de exemplu
grid-cols-[200px_1fr_300px]). - Valori dinamice sau temporare: Când testezi rapid o idee în browser și nu vrei să deschizi fișierul de configurare.
Trade-off-ul e simplu: câștigi viteză pe moment, dar pierzi complet controlul global. Dacă brandul se decide că acel galben ciudat trebuie înlocuit, te apuci de căutat prin zeci de fișiere .tsx.
Când trebuie să treci totul în tailwind.config.js
Dacă o valoare apare de mai mult de două ori în proiect, locul ei este în configurare sub formă de design token. Punct.
La proiectul menționat mai devreme, după ce am curățat parantezele pătrate și am definit culorile în config, am economisit cam 15% la timpul de development la următoarele tichete de UI. Developerii nu mai stăteau să măsoare cu pipeta în Figma ce nuanță de gri e acolo; scriau direct text-neutral-dark.
Design tokens (culori, fonturi, spacing, border-radius) îți oferă singura sursă de adevăr. Când folosești tokens, codul tău devine predictibil și ușor de citit de către orice coleg nou care intră pe proiect.
Concluzia mea
Arbitrary values sunt ca sarea în mâncare. Dacă pui un pic unde trebuie, dă gust. Dacă scapi solnița și umpli codul de w-[327px] și text-[#333], o să ai o aplicație greu de digerat și un refactoring dureros la primul redesign.
Voi cum gestionați asta în echipă? Aveți o regulă strictă în PR-uri împotriva parantezelor pătrate sau le lăsați să treacă dacă "merge și așa"?