// tailwind.config.js - Așa transformăm valorile arbitrare repetate în tokens curate
module.exports = {
theme: {
extend: {
colors: {
brand: {
500: '#2563eb',
600: '#1d4ed8',
}
},
spacing: {
'card-padding': '1.75rem', // 28px standardizat în loc de p-[28px]
}
}
}
}Am preluat acum câteva luni un proiect cu vreo 40 de componente unde echipa anterioară abuzase la greu de parantezele drepte. Aveam bg-[#1a2b3c], w-[347px], mt-[13px] și vreo 12 nuanțe de gri generate la liber. Tailwind îți oferă o libertate fantastică cu arbitrary values, dar dacă nu pui niște limite, ajungi rapid într-un haos vizual pe care nu-l mai poți refactoriza fără să spargi jumătate de aplicație.
Întrebarea pe care o primesc des de la juniori este simplă: când folosesc w-[something] și când mă ating de tailwind.config.js?
Tentanta paranteză dreaptă: de ce o scrii prima dată
Arbitrary values sunt excelente pentru că nu-ți taie momentum-ul când scrii cod. Ai un layout din Figma unde designerul a pus un div de 288px și nu vrei să stai 5 minute să cauți clasa echivalentă din scara implicită de spacing (care e w-72). Bagi rapid w-[288px] și mergi mai departe.
Am găsit la un audit peste 180 de clase arbitrary scrise doar în modulul de checkout. Problema nu e că le scrii o dată pentru un logo extern, un iframe sau o poziționare milimetrică la un popover ciudat. Problema apare când o valoare arbitrary devine regula tăcută din proiect. În momentul în care ai același p-[22px] în 5 fișiere diferite, sistemul tău de design a murit deja.
Când e timpul să treci în tailwind.config.js
Regula mea de bază pe care o aplic în cod-review-uri e destul de simplă: dacă o valoare vizuală (culoare, spațiere, rază de border) apare de mai mult de două ori pe ecran, își merită locul în config ca token de design.
La un proiect SaaS cu peste 10k utilizatori activi, refacerea culorilor de brand din arbitrary values în design tokens ne-a scăzut bundle-ul de CSS generat cu aproape 25% și a făcut trecerea la un nou UI kit un proces de două ore în loc de două săptămâni. Dacă schimbi culoarea primară de la un #2563eb la un #3b82f6, nu vrei să dai Find & Replace în 80 de fișiere JSX.
Ieși din sistemul de design doar când valoarea respectivă este o excepție matematică sau structurală, nu un element vizual de brand.
Trade-off-ul direct și excepțiile de la regulă
Design tokens îți dau consistență și mentenanță ușoară, dar vin cu un cost: mai multe decizii de numire (naming conventions) și mai mult boilerplate inițial. Arbitrary values îți dau viteză maximă în prototyping, dar îți ucid consistența pe termen lung.
Unde rămân totuși ultra-utile arbitrary values?
- Poziționări dinamice sau specifice:
top-[calc(100%-12px)] - Grid-uri custom unice:
grid-cols-[200px_1fr_120px] - Animații sau transformări CSS folosite o singură dată pe o pagină de landing.
Voi cum gestionați scăpările astea în echipele voastre? Lăsați devs să scrie arbitrary values la liber în PR-uri sau ați configurat deja linter-ul să dea țipete când vede paranteze drepte?