// tailwind.config.js - Cum structurăm corect excepțiile și token-urile
module.exports = {
theme: {
extend: {
colors: {
// Token-uri clare de brand, fără hex-uri în HTML
'brand-primary': '#0f172a',
'brand-accent': '#3b82f6',
},
spacing: {
// Util pentru chestii specifice de mobile/safe areas
'safe-bottom': 'env(safe-area-inset-bottom)',
}
}
}
}Lucrez cu Tailwind de prin versiunea 1 și am văzut ambele extreme. Ori dai peste config-uri de 800 de linii unde fiecare pixel e documentat ca "design token", ori vezi în cod chestii horror de genul p-[13px] și bg-[#f3f4f6] aruncate la întâmplare. Hai să vorbim sincer despre unde tragem linia ca să nu ne luăm zilele la următorul refactoring.
Capcana parantezelor pătrate (-[...])
Am avut un proiect acum doi ani, un dashboard destul de complex cu vreo 14 ecrane diferite. Designerul era nou în echipă, nu prea înțelegea conceptul de grid system și ne trimitea în Figma margini dubioase de 11px, 13px sau 19px. Din grabă și ca să "iasă la pixel perfect", băieții din echipă au început să bage m-[11px] sau w-[347px] peste tot în componente.
Ghici ce s-a întâmplat când clientul a vrut un audit de accesibilitate și a trebuit să uniformizăm spacing-ul? Am petrecut două zile pline doar curățând paranteze pătrate din peste 50 de fișiere Vue.
Arbitrary values sunt un mecanism de urgență (un "escape hatch"). Sunt excelente când ai un background-image specific (bg-[url('/hero-bg.png')]) sau o poziționare absolută unică. Dar când le folosești pentru culori repetitive sau spacing, ai pierdut deja controlul asupra design-ului.
Când definim design tokens în config?
Regula mea de aur e simplă: dacă o valoare apare de mai mult de 3 ori în pagini diferite, ea trebuie să devină token în tailwind.config.js.
Uite un caz clasic cu culorile de brand. Dacă ai text-[#2B6CB0] împrăștiat prin 20 de componente, ești la un pas de dezastru dacă brandingul se schimbă la primăvară.
Trade-off sincer: Config-ul extins înseamnă că Tailwind va genera clase specifice, dar măcar ai o singură sursă de adevăr. Partea proastă? Dacă exagerezi cu tokenizarea fiecărui detaliu, config-ul devine un monstru greu de întreținut și pierzi din viteza de development pentru că trebuie să verifici mereu "cum se numea clasa aia custom de gri".
Cum abordez eu lucrurile în mod practic
Pe proiectele curente aplic un set de reguli destul de stricte care ne-au salvat sute de ore de mentenanță:
- Spacing strict: Folosim exclusiv valorile default din Tailwind (multiplii de 4 pixeli). Dacă Figma zice
18px, facem push-back la design sau pur și simplu rotunjim la16px(p-4) sau20px(p-5). Crede-mă, nu moare nimeni din 2 pixeli diferență, iar codul rămâne curat. - Fără coduri HEX în HTML: Zero coduri hex în clase. Tot ce înseamnă culoare de brand, fundal sau text merge în config.
- Excepții acceptate pentru layout: Dacă am un element absolut care trebuie să stea la
top-[42px]din motive de aliniere cu un asset grafic dubios, folosesc arbitrary value fără regrete. E o excepție pur vizuală a acelei componente.
La final, totul se reduce la disciplină de echipă. Folosește arbitrary values pentru excepții matematice și layout hacks, nu ca scuză pentru un design sistem implementat prost.
Cum procedați la voi în echipă? Tolerați parantezele pătrate în codul de producție sau aveți lintere care le blochează?