// tailwind.config.js - fă asta pentru valori repetate
module.exports = {
theme: {
extend: {
width: {
sidebar: '280px',
},
colors: {
brand: {
DEFAULT: '#2563eb',
subtle: '#eff6ff',
}
}
}
}
}
// În componentă:
// BUN (Design Token): <aside className="w-sidebar bg-brand-subtle" />
// BUN (Arbitrary unic): <div className="rotate-[13deg] top-[3px]" />
// RĂU: <button className="bg-[#2563eb] w-[280px]" />Tailwind îți dă libertatea absolută să scrii w-[347px] sau bg-[#1a1f2c] direct în clase și să mergi mai departe fără să deschizi vreun config. E comod, rezolvă treaba pe moment, dar dacă nu ești atent, ajungi rapid să regreți decizia. Hai să vedem unde e utilă libertatea asta și unde devine o bombă cu ceas pentru mentenanță.
Capcana celor 14 nuanțe de gri
Am preluat la un moment dat un proiect de e-commerce cu vreo 12k vizitatori zilnici, la care lucraseră trei devi diferiți în decurs de un an. Când am rulat o căutare prin fișiere după paranteze drepte, am găsit 14 coduri HEX diferite doar pentru nuanțe de gri închis, de la text-[#1f2937] până la text-[#1e2836].
De ce se întâmplă asta? Designerul trage un pixel mai la stânga în Figma, exportă o culoare cu 1% diferență de opacitate, iar dev-ul grăbit dă copy-paste la valoarea brută în loc să folosească token-ul cel mai apropiat (text-slate-800). Când clientul a cerut Dark Mode șase luni mai târziu, estimarea a sărit de la două zile la două săptămâni doar pentru că a trebuit să luăm la mână fiecare componentă și să curățăm valorile hardcodate.
Când are sens să folosești arbitrary values
Nu sunt un purist extremist. Arbitrary values există cu un motiv bun și chiar rezolvă probleme reale în câteva scenarii clare:
- Elemente strict decorative sau unicate: ai un sticker cu o rotație ciudată de
rotate-[17deg]sau un gradient complex pe un landing page promoțional care nu se va mai repeta nicăieri. Nu are niciun sens să poluezitailwind.config.jscurotate: { sticker: '17deg' }. - Valori calculate dinamic: de exemplu, o înălțime de tip
h-[calc(100vh-64px)]pe un layout specific de dashboard. - Grid-uri complexe unice: un
grid-cols-[1fr_auto_280px]pe o pagină de profil arată mult mai clar scris direct în JSX decât inventat ca utilitar separat.
Trade-off-ul e simplu: câștigi viteză pe moment și eviți fișiere de configurare umflate artificial, dar pierzi complet consistența globală.
Regula mea: regula celor 2 apariții
Ca să nu transformăm code review-ul într-o ceartă filozofică, aplic o regulă foarte pragmatică în echipă:
- Dacă o culoare, o umbră sau o spațiere se repetă în mai mult de două locuri, devine obligatoriu Design Token în config (sau în noul fișier CSS dacă ești pe Tailwind v4).
- Dacă e o dimensiune fixă de structură (lățimi de sidebar, offset-uri de modale mari), se definește ca token semantin:
w-sidebar,max-w-modal.
La culori, regula e și mai strictă: zero paranteze drepte cu HEX-uri în componentele reutilizabile de UI (butoane, carduri, input-uri). Dacă Figma zice altceva, mai întâi vorbim cu designerul.