// tailwind.config.js - Exemplu de structură pentru scalare
module.exports = {
theme: {
extend: {
spacing: {
// Adaugă doar dacă e structural, nu pentru o singură imagine
'safe-top': 'env(safe-area-inset-top)',
},
colors: {
brand: {
50: '#f0f9ff',
// ... restul paletei
primary: '#0070f3',
}
}
}
}
}
// În componentă:
// ✅ OK: <div class="top-[137px] absolute">...</div> (excepție unică)
// ❌ NOT OK: <div class="bg-[#0070f3]">...</div> (folosește bg-brand-primary)M-am lovit recent de o dilemă într-un proiect nou, cu vreo 15 ecrane complexe în Figma: lăsăm echipa să folosească arbitrary values peste tot sau îi forțăm să bage orice unitate în config? E o linie fină între viteză și haos total, iar dacă nu ești atent, te trezești cu un codebase care arată ca un pom de Crăciun.
Tailwind ne-a dat libertatea asta cu JIT (Just-In-Time) și e fantastică, dar vine la pachet cu o responsabilitate uriașă. Am pățit la un proiect cu 8k useri activi să avem discrepanțe vizuale enorme doar pentru că trei developeri diferiți au interpretat "un pic mai la stânga" în trei moduri diferite: unul cu ml-4, unul cu ml-[18px] și altul cu ml-[20px]. Rezultatul? Un UI care părea nefinisat, deși tehnic toți respectaseră designul.
Când e ok să ieși din sistem
Arbitrary values (-[...]) sunt geniale pentru excepții absolute. Am avut cazul unui element decorativ, un fel de blob care trebuia să stea fix la top: 137px și left: -42px. Nu avea nicio legătură cu grid-ul, nu se repeta nicăieri. Dacă aș fi băgat valorile astea în tailwind.config.js, aș fi poluat fișierul de configurare cu niște token-uri pe care nu le-ar mai fi folosit nimeni niciodată.
E vorba de zgomot. Un config curat trebuie să conțină doar chestiile care definesc limbajul vizual al brandului. Dacă ai un splash screen care trebuie să aibă fix h-[432px] pe mobil, bagă-l direct în clasă. Te scapă de căutat prin fișiere și e clar pentru oricine citește codul că e o chestie punctuală.
Capcana numerelor magice
Problema apare când "excepția" devine regulă. Am preluat la un moment dat un codebase unde am găsit text-[#334455] de vreo 50 de ori în componente diferite. Niciun token de culoare. Când clientul a decis că vrea un gri un pic mai cald, am pierdut cam o zi întreagă cu search and replace și verificat să nu fi stricat altceva. Am calculat atunci că am pierdut cam 30% din timpul de sprint doar reparând inconsecvențe care ar fi fost rezolvate din start de un simplu colors.brand.gray în config.
Trade-off-ul e simplu: arbitrary values îți dau viteză pe moment, dar îți mănâncă timpul la mentenanță. Design tokens îți cer un efort inițial de organizare, dar fac scalarea mult mai ușoară. La proiecte mari, arbitrary values sunt, de cele mai multe ori, doar lene deghizată în pragmatism.
Regula mea de aur
După 10 ani de frontend, am ajuns la o regulă destul de simplă pentru echipa mea: dacă o valoare apare de mai mult de 3 ori în fișiere diferite, e timpul să devină token. Dacă e o chestie de layout unică, cum e un grid-cols-[200px_1fr_100px], e perfect în regulă să rămână arbitrary value.
Un alt aspect e colaborarea cu designerii. Dacă în Figma ai un spacing de 19px și sistemul tău e pe multipli de 4, nu te arunca să scrii p-[19px]. Mai bine întreabă designerul dacă nu cumva e o eroare de aliniere acolo. De cele mai multe ori, e o greșeală în Figma, nu o intenție de design. Folosind strict token-urile, forțezi și designul să rămână coerent.
Voi cum gestionați asta? Aveți un prag de la care ziceți "gata, asta merge în config" sau lăsați echipa să scrie ce vrea în parantezele alea pătrate?