// tailwind.config.js
// În loc de w-[320px] sau bg-[#0f172a] prin toate fișierele:
module.exports = {
theme: {
extend: {
colors: {
brand: {
base: '#0f172a',
accent: '#2563eb',
},
},
spacing: {
'sidebar': '320px',
},
},
},
};Să fim sinceri: parantezele drepte din Tailwind sunt cel mai comod drog din frontend. Scrii w-[317px] sau bg-[#0f172a] direct în JSX și ai rezolvat problema pe loc, fără să atingi vreun config. Problema apare 6 luni mai târziu, când clientul vrea rebranding sau dark mode, iar tu ai 40 de nuanțe de gri împrăștiate prin 200 de componente.
La un magazin online la care am lucrat acum doi ani, aveam vreo 14 developeri pe frontend. Am făcut un audit rapid cu un regex simplu prin fișiere și am găsit peste 400 de arbitrary values doar pentru culori și spacing. Rezultatul? Pagina de checkout avea 3 nuanțe ușor diferite de verde pe butoane, în funcție de cine scrisese componenta respectivă.
Când e total justificat să folosești arbitrary values
Nu sunt un purist rigid — dacă feature-ul există în Tailwind, înseamnă că are cazuri valide de uz. În experiența mea, parantezele drepte își au locul în exact trei scenarii:
- Layout-uri unice dictate de 3rd-party assets: Ai un banner promoțional cu o imagine de fundal tăiată ciudat la
min-h-[423px]. Nu are sens să poluezitailwind.config.jssau fișierul de temă cu o valoare pe care n-o mai folosește nimeni niciodată. - Grid-uri complexe sau dinamice:
grid-cols-[1fr_2fr_300px]e mult mai lizibil direct în markup decât o clasă abstractă definită într-un CSS separat. - Animare sau tranziții specifice: O durată de
duration-[450ms]legată de o animație SVG punctuală.
Regula mea de bun-simț: dacă o valoare apare o singură dată într-un ecran și e 100% specifică acelui ecran, parantezele drepte sunt ok.
Unde începe durerea: culori, tipografie și spațiere de bază
În momentul în care începi să scrii text-[#333333] sau p-[18px], ai ieșit de pe șine. Design tokens nu există doar ca să facă designerul fericit în Figma, ci pentru mentenanță pură.
Trade-off-ul e simplu: cu arbitrary values câștigi 30 de secunde pe moment, dar pierzi complet capacitatea de a schimba design-ul global. Când folosești text-muted-foreground sau p-4, beneficiezi instant de consistență vizuală și dark mode out of the box. Dacă bagi hex-uri hardcodate, dark mode devine un coșmar manual plin de dark:text-[#cccccc] repetat obsesiv.
În plus, dacă designerul vine cu un grid de 4px sau 8px, p-[18px] e probabil o greșeală din Figma pe care tu o perpetuezi în cod în loc să-l tragi de mână.
Soluția pragmatică: definește un token când se repetă de două ori
Nu trebuie să prevezi tot sistemul de design din prima zi. Dacă observi că folosești min-h-[72px] pentru a doua oară (de exemplu, la un header și la un sticky bottom bar), acela nu mai e caz particular. E o dimensiune de navigație.
O muți frumos în theme config sau în variabile CSS dacă folosești Tailwind v4. În felul ăsta, codul rămâne curat, iar cine vine după tine înțelege ce reprezintă clasa, nu doar câți pixeli are pe ecran.
Voi cum gestionați parantezele drepte în echipă? Le aveți blocate prin linting sau mergeți pe încredere?