// tailwind.config.js
module.exports = {
theme: {
extend: {
colors: {
brand: {
50: '#f0f7ff',
500: '#0066ff', // Folosit ca bg-brand-500 în loc de bg-[#0066ff]
900: '#002266',
}
},
spacing: {
'18': '4.5rem', // Extindere curată când sistemul standard de 4px nu ajunge
}
}
}
}Am refăcut recent un frontend unde jumătate din clase erau w-[342px] sau bg-[#1a1a2e]. Parantezele pătrate din Tailwind sunt fantastice când ai de rezolvat ceva rapid, dar devin un munte de debt tehnic dacă exagerezi. Dacă te întrebi când e ok să pui o valoare arbitrară și când trebuie să treci la design tokens în config, hai să-ți arăt cum tranșez eu problema asta în producție.
Problema de la care am plecat
Anul trecut am preluat o aplicație cu peste 15k utilizatori activi. Codul arăta ok la prima vedere, dar echipa anterioară scăpase complet sub control valorile arbitrare. Am găsit în proiect peste 400 de instanțe de culori hardcodate cu #HEX și margini ciudate gen mt-[13px] sau p-[18px].
Când clientul a cerut un rebrand minor — practic o ajustare de nuanță la culoarea primară și rotunjimi mai mari la carduri — ne-a luat 3 zile pline doar să căutăm prin componente. Am pierdut vreo 30% din timpul sprintului făcând Replace All și rezolvând bug-uri vizuale create de scăpări. Atunci am zis stop.
Când au sens arbitrary values (w-[123px])
Nu sunt absurd, parantezele pătrate își au rostul lor. Nimeni nu vrea să adauge o clasă globală în config pentru un caz izolat dintr-o pagină uitată de lume.
Folosesc valori arbitrare doar pentru:
- Elemente terțe sau SVG-uri fixe: Dacă primești de la un provider un widget care trebuie să aibă fix
w-[180px]și nu se va schimba niciodată. - Layout-uri extrem de specifice: Un grid ciudat cu
grid-cols-[1fr_2fr_120px]folosit într-un singur dashboard. - CSS Custom Properties integrate: Ceva de genul
h-[calc(100vh-var(--header-height))].
Trade-off-ul e simplu: scrii cod super rapid azi, dar plătești cu dobândă mai târziu dacă repeți valoarea aia în altă componentă.
Când e obligatoriu să treci pe Design Tokens
Dacă o valoare apare de mai mult de două ori în proiect, locul ei este în tailwind.config.js. Punct. Asta e regula mea simplă pe care o impun la code review.
Design tokens (culori, spacing, typography, shadows) îți oferă un singur sursă de adevăr. În loc să ai #0f172a împrăștiat în 50 de fișiere .tsx, definești brand-dark în theme. Când designerul schimbă paleta, modifici o singură linie și tot aplicația se actualizează instant.
Mai mult, tokens-urile ajută la autocompletion în editor. Juniorii din echipă nu mai trebuie să inspecteze Figma din pixel în pixel ca să ghicească ce nuanță de gri am folosit la border — tastează border-slate- și IDE-ul le sugerează fix valorile permise din sistem.
Cum arată un echilibru sănătos
În proiectele actuale configurăm mereu tokens clare în theme.extend. Dacă designerul a creat o scară de spațiere bazată pe 4px, o respectăm pe aceea. Când un dev simte nevoia să pună padding: 17px, e un semnal clar că fie designerul a greșit în Figma, fie dev-ul e leneș.
Morala e scurtă: folosește parantezele pătrate ca pe o excepție, nu ca pe stilul tău implicit de scris Tailwind.
Voi cum gestionați asta în echipele voastre? Aveți linter care blochează arbitrary values sau lăsați libertate deplină?