// tailwind.config.js - Folosește asta pentru chestii globale
module.exports = {
theme: {
extend: {
colors: {
brand: '#1a2b3c', // Token: se repetă peste tot
},
spacing: {
'13': '3.25rem', // Dacă chiar ai nevoie de pasul ăsta în grid
}
}
}
}
// component.jsx
// Folosește arbitrary values pentru excepții locale
<div className="bg-brand p-[11px] lg:mt-[-2px]">
Conținut care are nevoie de offset fix
</div>Salutare. Recent am făcut un code review pe un proiect unde echipa se bătea în comentarii pe marginea unui w-[347px]. Unii ziceau că e „magie neagră” și că strică sistemul de design, alții argumentau că n-are rost să poluezi fișierul de config pentru o singură imagine de hero. După 10 ani de frontend, m-am prins că adevărul nu e la mijloc, ci depinde de cât de mult vrei să dormi liniștit peste șase luni.
Arbitrary values (acele clase cu paranteze pătrate) sunt gura de aer de care aveam nevoie toți înainte să apară motorul JIT (Just-In-Time) în Tailwind. Înainte, dacă voiai un z-index atipic, trebuia să te rogi de tailwind.config.js și să dai restart la build. Acum e simplu. Dar libertatea asta e periculoasă dacă nu ai un set de reguli interne.
Magia lui -[...] și când devine blestem
Am pățit-o la un proiect cu vreo 12k useri unde, dintr-o lene combinată cu grabă, am început să bag culori hex direct în clase: text-[#34d399]. Merge brici la început. Problema apare când clientul zice: „Știi, verdele ăsta de brand e un pic prea deschis pe ecranele noi, hai să-l închidem cu 5%”. Dacă ai valoarea aia împrăștiată în 40 de componente, ai pierdut jumătate de zi cu search & replace și testat să nu fi stricat ceva.
Arbitrary values sunt geniale pentru „one-offs”. Ai un element decorativ care trebuie să stea la fix top-[13px] ca să se alinieze cu un logo prost tăiat? Bagă-l în paranteze pătrate. E mult mai cinstit să vezi acea valoare ciudată direct în HTML și să înțelegi că e o excepție, decât să creezi un token de tipul spacing-logo-offset-mobile pe care nu-l va mai folosi nimeni niciodată.
Când e obligatoriu să te întorci în tailwind.config.js
Regula mea de aur e simplă: dacă o valoare apare de mai mult de trei ori în locuri diferite, e timpul să devină design token. La un dashboard complex la care am lucrat, am făcut greșeala să bag toate culorile de grafice (vreo 20 la număr) în config din prima zi. Rezultatul? Un fișier de configurare de 500 de linii pe care nu-l mai înțelegea nimeni.
Am economisit cam 30% din timpul de mentenanță ulterior după ce am făcut curat și am lăsat în config doar fundamentul: paleta de culori de brand, fonturile și pașii de spacing (grid-ul de bază). Tot ce e specific unei singure componente și nu se repetă, l-am mutat în clase arbitrare sau, unde era prea mult zgomot, în CSS variables locale.
Trade-off-ul între viteză și consistență
Folosirea exclusivă a token-urilor (config-ul) îți dă acea siguranță că totul e „on-brand”, dar te încetinește enorm când ai de făcut prototipuri rapide sau layout-uri de marketing care nu respectă nicio regulă. Pe de altă parte, abuzul de arbitrary values transformă codul într-o ciorbă de numere magice greu de urmărit.
Un pont pentru cei care lucrează în echipe mari: Tailwind are o funcționalitate mai puțin cunoscută care îți permite să limitezi sau să avertizezi când se folosesc arbitrary values, dar eu prefer să las libertate dev-ilor, cu condiția să aibă bun simț.
În concluzie, dacă e o valoare structurală (padding, margin, culori de bază), pune-o în config. Dacă e un „hack” vizual pentru a repara o problemă de aliniere unică, folosește parantezele pătrate fără nicio remușcare. Voi cum procedați? Aveți o limită de „numere magice” per componentă înainte să le urcați în sistemul de design?