// tailwind.config.js - Așa fixezi valorile recurente
module.exports = {
theme: {
extend: {
colors: {
brand: {
DEFAULT: '#1d4ed8',
surface: '#f8fafc',
}
},
spacing: {
'card-header': '52px',
}
}
}
}Am văzut de prea multe ori baze de cod pline de h-[53px], bg-[#1a202c] și p-[17px]. Parcă uităm uneori de ce am adoptat Tailwind: ca să scăpăm de valori magice scrise la nimereală și să lucrăm cu un sistem coerent. Azi discutăm scurt despre când e ok să folosești arbitrary values și când ar trebui să le trimiți direct în tokens.
Ce am pățit într-un proiect cu 220 de componente
Anul trecut am preluat un proiect de e-commerce la care lucraseră trei freelanceri anteriori. La un audit rapid pe cod, am găsit peste 400 de instanțe de paranteze drepte (w-[...], text-[...], color-[...]).
Dezastrul a început când designerul a schimbat nuanța de brand din #2563eb în #1d4ed8 și a modificat border-radius-ul pe carduri. În loc să schimbăm o singură linie în configurație, am stat o zi întreagă cu search & replace prin tot proiectul, testând cu frică să nu stricăm ceva. Am pierdut timp aiurea doar pentru că echipa anterioară a fost prea leneșă să configureze un token.
Când au sens arbitrary values (Trade-off-ul real)
Să fim clari: sintaxa cu paranteze drepte e un caracteristică excelentă în Tailwind. Este un "escape hatch" (o cale de scăpare) gândit exact pentru situațiile de margine. Problema nu e sintaxa în sine, ci abuzul.
Arbitrary values își au locul în doar câteva scenarii speciale:
- Valori dinamice sau calculate: Un grid cu număr de coloane primit direct din backend, un progress bar unde setezi
w-[var(--progress-percent)]sau un avatar cu background dynamic. - Integrări cu pachete terțe: Ai un widget iFrame de la un procesator de plăți care cere fix
w-[380px]și n-are nicio legătură cu restul aplicației. - Micro-ajustări pentru assets fixe: O imagine vectoriala sau un logo care se afișează ciudat dacă nu îi pui exact
h-[18px].
În schimb, dacă folosești bg-[#0f172a] pentru că ți-a fost lene să cauți numele culorii în sistem, creezi datorie tehnică pură. E rapid pe moment, dar devine un iad la mentenanță.
Regula mea de aur pentru tokens
Dacă o valoare spațială sau o culoare apare de mai mult de două ori în fișiere diferite, trebuie să ajungă în design tokens.
În Tailwind v3 faceai asta extinzând tema în tailwind.config.js. În Tailwind v4 e și mai simplu, pentru că totul se rezolvă prin variabile CSS directe în fișierul principal. Când ai un token clar (de exemplu bg-brand-primary sau rounded-card), codul tău devine autodescriptiv. Un junior va înțelege imediat ce rol are elementul respectiv, spre deosebire de un bg-[#1e293b] opac.
Arbitrary values sunt excepția, nu stilul implicit. Dacă ai mai mult de 5% paranteze drepte în aplicație, e un semnal clar că ai o problemă de comunicare cu designerul sau că echipa ignoră ghidul de stil.
Voi cum gestionați cazurile astea în echipă? Lăsați devs să scrie paranteze drepte la liber sau aveți reguli de linter care le blochează?