// tailwind.config.js
module.exports = {
theme: {
extend: {
colors: {
brand: {
primary: '#1e40af',
secondary: '#0f172a',
accent: '#f59e0b'
}
},
spacing: {
'header-height': '72px',
'sidebar-width': '260px'
}
}
}
}Am văzut prea multe codebase-uri Tailwind unde config-ul e aproape gol, dar codul e plin de clase gen top-[17px] sau text-[#3a3af2]. Am pățit-o chiar eu la un proiect cu peste 12.000 de utilizatori activi, unde a trebuit să implementăm un dark mode rapid. Ne-am lovit de un zid de valori arbitrare scrise direct în markup de foști colegi care se grăbeau. A fost nevoie de trei zile de search-and-replace manual doar ca să curățăm mizeria.
Arbitrary values (w-[347px], bg-[#ff0055]) sunt o binecuvântare atunci când prototipezi ceva rapid. Totuși, dacă le folosești ca pe o scuză ca să nu definești un sistem vizual clar, îți sapi singur groapa.
Capcana lui „las' că merge așa”
De ce apar valorile arbitrare? Simplu: designul nu se aliniază cu grid-ul sau echipa de UI a venit cu o culoare nouă pentru un singur buton. În loc să deschizi tailwind.config.js și să definești un token clar, trântești un bg-[#bfdbfe] direct în clasă.
Merge brici pe moment, dar e groaznic pe termen lung. Trade-off-ul e destul de brutal: câștigi 10 secunde la scrierea codului, dar pierzi complet consistența vizuală. Dacă brandul își schimbă albastrul de bază, succes la căutat prin zeci de fișiere .tsx sau .vue după coduri hexadecimale uitate.
Când e complet justificat să ieși din sistem
Nu mă înțelege greșit, nu sunt un extremist al token-urilor. Există cazuri unde chiar ai nevoie de flexibilitatea asta.
De exemplu, când ai de-a face cu elemente dinamice sau poziționări ultra-specifice. Dacă ai o bară de progres care vine din baza de date, e logic să folosești ceva de genul style={{ width: ${progress}% }} sau, în Tailwind, o clasă dinamică dacă setul de valori e finit. De asemenea, e perfect în regulă să folosești o valoare arbitrară pentru un layout hack pe o singură pagină, de exemplu un grid custom complex care nu se va mai repeta niciodată în restul aplicației: grid-cols-[200px_1fr_300px].
Regula de aur: Cum organizez lucrurile
Eu aplic o regulă simplă pe care am învățat-o după multe refactorizări dureroase:
- De maxim două ori: Dacă o valoare (o culoare, o dimensiune de padding sau o umbră) apare în mai mult de două locuri în aplicație, o mut instant în
tailwind.config.jssub formă de design token. - Excepțiile rămân în pagină: Dacă e un banner temporar de Crăciun cu o culoare specifică, folosesc arbitrary values fără remușcări.
Aruncă o privire peste cum ar trebui să arate un config curat care extinde sistemul standard, fără să-l distrugă pe cel nativ. În loc să inventezi culori în markup, le mapăm semantic în config.