// tailwind.config.js - Extinde tema, nu o suprascrie complet direct în markup
module.exports = {
theme: {
extend: {
colors: {
brand: {
primary: '#1e40af', // Folosește bg-brand-primary în loc de bg-[#1e40af]
secondary: '#0f172a',
}
},
spacing: {
'18': '4.5rem', // Adaugă dimensiuni lipsă dacă designul o cere des
}
}
}
}Ne lovim zilnic de asta când scriem Tailwind: punem o valoare direct în clasă cu paranteze pătrate sau o definim frumos în config? Ambele variante au sens, dar limita e extrem de subțire și ușor de încălcat.
Povestea din spatele parantezelor pătrate
Am preluat acum un an un proiect cu vreo 140 de componente, unde fostul dev abuzase grav de arbitrary values. Era plin de clase gen h-[73px], w-[290px] și culori scrise direct în cod ca text-[#2d3748]. Am numărat peste 400 de instanțe de genul ăsta aruncate prin markup.
Când clientul a cerut un rebranding minor și un mod întunecat (dark mode), a început coșmarul. A trebuit să dăm search and replace în tot codul, sperând că n-am spart layout-ul în locuri ascunse. Am pierdut vreo 3 zile de muncă doar curățând mizeria asta, timp în care puteam livra feature-uri reale în loc să repar chestii de bază.
Când trebuie să folosești Design Tokens
Regulile mele acum sunt destul de simple și le aplicăm riguros la code review. Dacă o valoare apare de mai mult de două ori în design, zboară direct în tailwind.config.js.
Spațiile, culorile de brand, fonturile și umbrele sunt sfinte. Trebuie să fie tokens. Altfel, pierzi consistența vizuală instant. Un buton cu px-4 și altul cu px-[17px] arată ciudat și neprofesionist, chiar dacă ochiul neantrenat nu își dă seama imediat de ce. În plus, când ai totul în config, poți schimba tema întregului site în 10 secunde din config-ul central.
Trade-off-ul sincer: când sunt utile valorile arbitrare?
Nu sunt absurd, parantezele pătrate au utilitatea lor. Trade-off-ul e simplu: câștigi viteză de execuție pe moment, dar pierzi mentenanță pe termen lung dacă le folosești ca pe un obicei prost.
Le folosesc fără remușcări în două cazuri specifice:
- Layout-uri unice: O poziționare absolută ciudată pentru o ilustrație pe o pagină de marketing (ex:
top-[137px]). Nu mai folosesc acea poziție nicăieri altundeva, deci nu are sens să poluez config-ul global cu valori inutile. - Grid-uri complexe: Când am nevoie de o structură de coloane foarte specifică, cum ar fi
grid-cols-[200px_1fr_300px]. E mult mai lizibil direct în HTML decât să inventez un token gengrid-cols-custom-layoutîn config.
Ideea e să nu fii leneș. Dacă folosești bg-[#ff0000] pentru că ți-a fost lene să adaugi culoarea danger în config, peste 6 luni o să regreți decizia asta.
Voi cum gestionați asta în echipă? Aveți reguli stricte la code review sau mergeți pe bunul simț al fiecăruia?