// tailwind.config.js
module.exports = {
theme: {
extend: {
colors: {
brand: {
light: 'var(--color-brand-light, #3fbaeb)',
DEFAULT: 'var(--color-brand-main, #0fa9e6)',
dark: 'var(--color-brand-dark, #0c8ec2)',
}
},
spacing: {
// Evită să pui valori ciudate gen '13px' direct aici
// folosește-le doar dacă devin un standard în design system-ul tău
'18': '4.5rem',
}
}
}
}Salutare! Hai să vorbim despre cum ne furăm singuri căciula cu Tailwind CSS. Mai exact, când e ok să folosești arbitrary values (bg-[#ff0000]) și când ar trebui să-ți pui cenușă în cap și să le muți în config.
Ispita lui "merge și așa"
Am pățit-o acum vreo doi ani la un proiect mărișor. Aveam cam 50 de ecrane în Figma și trei developeri pe frontend. Designerul, un tip talentat dar cam haotic, a venit cu niște spațieri destul de dubioase. Ba aveam margini de 13px, ba padding de 27px, plus niște culori care variau cu câte o nuanță absolut insesizabilă.
Soluția noastră rapidă? Am umplut codul de clase de tipul mt-[13px], w-[342px] și bg-[#f3f4f7]. La început a fost parfum. Am livrat repede, clientul a fost fericit, toată lumea mulțumită.
Dezastrul a bătut la ușă după vreo trei luni. Designerul a decis să facă curățenie în Figma și să treacă totul pe o grilă curată, cu multipli de 4px. Spor la căutat și înlocuit manual prin zeci de fișiere Vue ca să schimbi [13px] în [12px] sau [16px]. Atunci mi-am promis că nu mai fac asta niciodată.
Regula mea de aur pentru arbitrary values
Nu zic să fim extremiști. Arbitrary values sunt o super-putere în Tailwind, dar vin cu un cost imens de mentenanță dacă scapi hățurile din mână. În timp, mi-am format o regulă destul de simplă.
Folosesc arbitrary values DOAR pentru chestii ultra-specifice, de layout, care nu se vor repeta niciodată în altă parte a aplicației. De exemplu:
- O poziționare absolută ciudată pentru un element decorativ:
top-[11%] left-[34px]. - O imagine de fundal specifică unui singur ecran:
bg-[url('/hero-bg.webp')]. - Un grid ciudat cu dimensiuni fixe cerute de un widget extern.
Dacă văd că scriu aceeași valoare arbitrară de trei ori în locuri diferite, e clar ca lumina zilei. E timpul pentru refactoring în config.
Cum structurăm tokens fără să o luăm razna
Trade-off-ul sincer e că tailwind.config.js îți rupe un pic flow-ul de lucru. E enervant să te oprești din scris HTML ca să deschizi configul, să adaugi o culoare, să te asiguri că nu strici ceva și abia apoi să o folosești.
Dar merită efortul pentru culori, fonturi și umbre. De exemplu, dacă ai text-[#2B3A42] peste tot, definește-o semantic în config ca brand-dark sau neutral-dark. Am economisit cam 30% din timpul de refactoring la un rebranding recent doar pentru că am avut culorile mapate corect, în loc de hex-uri trântite direct în clase.
Un alt truc bun e să folosești CSS variables în config. În loc să scrii hex-ul direct în JavaScript, pui o variabilă CSS. Astfel, dacă ai nevoie de dark mode sau de teme dinamice pe viitor, schimbi doar valoarea variabilei din CSS, iar Tailwind își face magia fără să mai atingi config-ul.
În loc să ai codul plin de valori magice, mai bine extinzi tema în config. Uită-te la exemplul de mai jos pentru o structură curată.
Voi cum procedați în echipă? Îi lăsați pe developeri să bage arbitrary values la liber sau aveți reguli stricte la code review?