// tailwind.config.js - Așa extindem tema corect
module.exports = {
theme: {
extend: {
colors: {
brand: {
50: '#f0f9ff',
500: '#0284c7',
900: '#0c4a6e',
},
},
spacing: {
'card-gap': '1.75rem', // 28px reutilizabil
}
},
},
}
// Bad usage in JSX:
// <div className="bg-[#0284c7] p-[28px] text-[15px]">...</div>
// Good usage in JSX:
// <div className="bg-brand-500 p-card-gap text-sm">...</div>Parantezele drepte din Tailwind, gen top-[17px] sau bg-[#1a202c], sunt cea mai mare binecuvântare și cel mai mare blestem din versiunile recente. Te scot din încurcătură instant, dar pot transforma o aplicație îngrijită într-un ghiveci vizual în mai puțin de două sprinturi. Dacă ai folosit vreodată mai mult de zece valori arbitrare într-un singur fișier, discuția asta e pentru tine.
Cum am ajuns să curăț 300+ de valori arbitrare
Anul trecut lucram la un SaaS pe zona de fintech, un dashboard cu vreo 14.000 de useri activi zilnic. Echipa de design a decis să schimbe paleta de culori neutre și padding-ul pe carduri. În mod normal, schimbi 4-5 variabile în config și ai terminat în zece minute.
În schimb, ne-am trezit că aveam peste 300 de clase precum bg-[#0f172a], px-[18px] și h-[calc(100vh-64px)] aruncate direct prin componentele noastre de React. Am pierdut aproape 3 zile întregi dând find-and-replace cu frica în sân că o să stricăm ceva pe producție.
Atunci m-am prins că mulți juniori folosesc w-[320px] nu pentru că au o nevoie tehnică reală, ci pentru că le e lene să deschidă tailwind.config.js sau să-i spună designerului că 18px padding nu există în grid-ul stabilit.
Regula de aur: când au sens parantezele drepte [...]
Să fim clari: parantezele drepte nu sunt un anti-pattern în sine. Au fost create pentru cazuri de margine reale și își fac treaba excelent acolo.
Am avut situații în care trebuia să poziționez un pointer de tooltip exact la un offset dinamic calculat din JS, sau când trebuia să integrez o grafică SVG de la un vendor extern cu dimensiuni fixe neobișnuite. În cazurile astea, left-[var(--tooltip-offset)] sau w-[312px] e o soluție curată. Nu are niciun sens să umpli configurația globală cu obiecte pe care le folosești o singură dată într-un colț izolat din aplicație.
Când DEBUIE să te lipești de tokens
Trade-off-ul e simplu. Arbitrary values îți dau viteză de scriere pe moment, dar îți ucid mentenanța pe termen lung. Tokens (adică ce declari în theme.extend) îți cer 30 de secunde în plus la setup, dar îți salvează ore la refactoring.
Dacă te prinzi că folosești aceeași culoare hex bg-[#10b981] în două componente diferite, e deja un semnal clar de alarmă. Aia nu e o valoare arbitrară, e o culoare de brand. Dacă ai max-w-[1280px] pe trei pagini, ăla e un container token.
Punctele unde recomand să nu folosești NICIODATĂ paranteze drepte:
- Culorile primare, secundare și stările vizuale (border, focus, hover)
- Spacing-ul de layout (padding de pagină, margin între secțiuni)
- Breakpoint-urile de media queries (
min-w-[768px]e o greșeală când aimd:) - Font-family și dimensiunile de text
Cum păstrezi disciplina în echipă
În loc să lași pe toată lumea să scrie ce hex îi pică la mână din Figma, extinde tema curat. Dacă designerul vine cu 13px padding într-un cadru, vorbește cu el înainte să scrii p-[13px]. În 90% din cazuri e o greșeală neintenționată din Figma, nu un token nou.
Voi cum gestionați asta în proiecte? Lăsați libertate totală pe valori arbitrare sau aveți reguli de Stylelint / ESLint care blochează PR-ul dacă văd hex-uri în JSX?