// tailwind.config.js
module.exports = {
theme: {
extend: {
spacing: {
'13': '13px', // Adăugat doar dacă designerul insistă că e o regulă de sistem
},
colors: {
brand: {
active: '#00f2fe',
}
}
}
}
}Ne-am lovit cu toții de faza asta: ai de făcut un layout rapid și designerul îți dă o margine dubioasă de 13px care nu există în grid-ul standard. Te mănâncă degetele să trântești un m-[13px] și să-ți vezi de viață. Hai să vorbim sincer despre când e ok să folosești arbitrary values în Tailwind și când îți sapi singur groapa dacă nu le pui în config.
Capcana lui "e doar o excepție"
La un proiect de acum un an, un dashboard pentru o clinică medicală cu vreo 15.000 de utilizatori activi, am făcut greșeala să fim prea permisivi. Am lăsat echipa să folosească arbitrary values (bg-[#00f2fe], text-[15px], h-[482px]) pe ideea că livrăm repede versiunea beta și vedem noi după aia ce și cum refactorizăm.
După șase luni, clientul a vrut un rebranding minor: trebuia să schimbăm nuanța principală de albastru și să trecem la un font-size de bază puțin mai mare pentru accesibilitate. Am petrecut două nopți cu search and replace prin 120 de componente Svelte, înjurând fiecare clasă cu paranteze pătrate. Am pierdut timp aiurea și am introdus și vreo trei bug-uri vizuale pe care le-am reparat abia după ce au urlat clienții în producție.
Când e absolut OK să folosești arbitrary values
Nu vreau să fiu extremist. Parantezele alea pătrate n-au fost introduse degeaba în Tailwind. Sunt geniale pentru chestii dinamice sau ultra-specifice care nu au nicio legătură cu identitatea vizuală generală a proiectului.
Am învățat că sunt perfecte în următoarele cazuri:
- Poziționări absolute ciudate (un indicator de notificare care trebuie să stea la
top-[3px] right-[-2px]). - Valori calculate dinamic la runtime (deși acolo de multe ori e mai bine să folosești inline styles cu proprietăți CSS custom).
- Grid-uri custom unice, cum ar fi
grid-cols-[200px_1fr_300px]pe un layout de admin.
Trade-off-ul e simplu: arbitrary values îți oferă viteză maximă pe moment, dar pierzi complet controlul centralizat. Dacă acea valoare se repetă în trei locuri diferite, deja ai trecut granița spre un "design system" paralel și nedeclarat.
Regula mea de aur: de la 3 în sus
După pățania cu dashboard-ul, am impus o regulă simplă în echipă. Dacă folosești aceeași valoare arbitrară în trei fișiere diferite, e obligatoriu să o muți în config-ul de Tailwind sub formă de design token.
În plus, extinderea temei te forțează să ai o discuție cu designerul. Când îi spui „auzi, ai pus aici un spacing de 11px, e greșeală în Figma sau chiar vrei un token nou?”, de cele mai multe ori o să-ți zică „ah, scuze, trebuia să fie 12px (space-3)”. Economisești timp și cod curat doar punând întrebarea asta.
Config-ul nu e doar o listă de variabile, e contractul tău cu echipa de design. Când adaugi un token nou, de exemplu colors.brand.active, te asiguri că toată lumea folosește aceeași nuanță, nu cinci variante diferite luate cu eyedropper-ul din Figma de către developeri obosiți la ora 5 după-amiaza.
Voi cum gestionați asta în echipe? Aveți reguli stricte în linter sau lăsați free-for-all în PR-uri până când începe să se spargă layout-ul?