// tailwind.config.js - Bună practică: extinde temele, nu le ocoli în clase
module.exports = {
theme: {
extend: {
colors: {
brand: {
50: '#f5f7ff',
500: '#4f46e5',
900: '#1e1b4b',
},
surface: {
subtle: '#1f2937',
muted: '#111827',
}
},
borderRadius: {
'card': '14px', // folosește rounded-card în loc de rounded-[14px]
}
},
},
}Toți am făcut asta măcar o dată: ai un element în Figma care refuză să se alinieze la grila de 4px și trântești un top-[13px] sau bg-[#2a2b36]. E rapid, trece de code review dacă reviewer-ul e obosit și livrezi sprintul la timp. Dar dacă nu știi când să te oprești, proiectul devine o ciorbă de stiluri imposibil de actualizat.
Capcana parantezelor pătrate
Arbitrary values (w-[347px], text-[#4a5568]) au fost cel mai bun feature adăugat în Tailwind JIT. Îți dau libertate totală fără să ieși din HTML ca să scrii CSS clasic.
Problema apare când libertatea asta devine scuza supremă pentru lene. La o aplicație de dashboard intern cu vreo 40 de ecrane, am făcut audit de CSS după un an de dezvoltare. Am găsit 17 nuanțe diferite de gri apropiat (de la #1e1e1e până la #232323) și vreo 6 variante de font-size create prin paranteze pătrate. Când clientul a cerut un rebranding pe culorile primare și dark mode, am pierdut 3 săptămâni făcând find-and-replace manual, în loc să schimb 4 variabile în config și să termin treaba în două ore.
Când e perfect în regulă să folosești arbitrary values
Nu trebuie să fii fanatic al design tokens-urilor. Există situații unde configurarea unui token e o pierdere completă de timp:
- Layout-uri unicat și grid-uri complexe: Dacă ai o pagină cu un grid specific gen
grid-cols-[240px_1fr_320px]care apare exclusiv pe ecranul de analytics, nu are niciun sens să definești asta în config. - Poziționări absolute ciudate: Pentru iconițe de background, decorațiuni grafice sau tooltip-uri unde ai nevoie de
translate-x-[-50%] top-[7px], folosește parantezele. - Valori calculate dinamic: Dacă calculezi o lățime de progress bar sau o înălțime dependentă de date:
w-[calc(100%-48px)].
Trade-off-ul e simplu: dacă valoarea aia moare odată cu componenta respectivă și nu afectează identitatea vizuală a brandului, nu-ți bate capul cu tokens.
Când trebuie să te oprești și să deschizi config-ul
Regula mea de bază e clară: culorile, spațierile de bază, tipografia și radius-ul aparțin sistemului de design. Niciodată nu lași un hex code arbitrar într-un buton sau într-un card comun.
Când primești în Figma un buton cu bg-[#6366f1] și rounded-[10px], întreabă întâi designerul dacă acel 10px chiar e intenționat sau dacă nu cumva a tras de colțuri din greșeală și trebuia să fie rounded-lg (8px) sau rounded-xl (12px). În 80% din cazuri, e o neatenție în Figma. Dacă chiar e intenționat și devine noul standard, îl pui în tailwind.config.js sau în noul block @theme dacă ești deja pe Tailwind v4.
Voi cum gestionați parantezele pătrate la code review? Le treceți cu vederea sau aveți lintere care dau fail pe hex-uri în clase?