module.exports = {
theme: {
extend: {
colors: {
brand: {
primary: '#3b82f6',
dark: '#1e3a8a',
accent: '#f59e0b'
}
},
spacing: {
'header-height': '64px',
'sidebar-width': '240px'
}
}
}
}Hai să vorbim pe șleau despre Tailwind. Toată lumea laudă flexibilitatea claselor utilitare, dar există un punct unde lucrurile o iau razna: bătălia dintre valorile arbitrare, gen w-[237px], și token-urile din config. Dacă nu pui o barieră clară acum, peste șase luni o să plângi când clientul cere un rebranding rapid.
Am văzut prea multe baze de cod distruse de ambele extreme. Ori avem o configurare gigantică în care s-a definit un token până și pentru un offset de 1px la un icon, ori avem un haos complet unde fiecare folosește ce culoare vrea prin paranteze pătrate.
Cum am umplut o aplicație cu h-[51px]
Am avut un proiect anul trecut, un SaaS de analytics cu vreo 12.000 de utilizatori activi lunar. Termenele erau strânse, designerul ne trimitea ecrane noi în Figma în fiecare zi, iar el nu folosea un design system coerent. Ce-am făcut noi, ca programatori grăbiți? Am trântit h-[51px], text-[#2d3748] și top-[13px] peste tot în cod.
După 4 luni, designerul s-a hotărât că vrea să schimbe culoarea principală de brand și înălțimea headerului. Am petrecut două zile cu search and replace prin 150 de componente Vue, sperând să nu fi stricat ceva în layout-urile vechi. Am pierdut timp aiurea și am lăsat în urmă un cod plin de inconsistențe. Atunci mi-am învățat lecția: arbitrarele sunt ca fast-food-ul. Îți potolesc foamea repede, dar te distrug pe termen lung dacă faci un obicei din asta.
Când e complet OK să folosești arbitrare
Nu mă înțelege greșit, nu sunt extremist. Valorile arbitrare (-[...]) sunt geniale pentru chestii unice, care nu se vor repeta niciodată în interfață.
Merge brici pentru:
- Poziționări absolute foarte specifice (de exemplu, un element decorativ care trebuie să stea exact la
top-[117px]). - Grid-uri custom unde ai nevoie de o structură ciudată pe o singură pagină, gen
grid-cols-[2fr_1fr_120px]. - Background-uri cu imagini dinamice venite din CMS.
Trade-off-ul e simplu: e rapid de scris, dar e groaznic de întreținut dacă acea valoare se repetă în mai mult de două locuri. Dacă vezi că scrii bg-[#1a1a1a] în trei componente diferite, oprește-te. Deja ai un design token nedeclarat.
Unde tragem linia în config
Eu acum aplic o regulă strictă pe proiecte. Culorile, fonturile, rotunjimile majore (border-radius) și spațierile de bază (padding/margin globale) TREBUIE să fie în config.
În loc să lași echipa să pună culori din burtă, extinde tema în tailwind.config.js. Astfel, asiguri consistența vizuală și, cel mai important, poți face modificări globale într-un singur loc.
Cum gestionați voi asta în echipă? Aveți reguli stricte de review sau lăsați pe fiecare să bage arbitrare cum îl taie capul?