module.exports = {
theme: {
extend: {
// TOKENS: Culorile brandului sunt sfinte, le punem aici
colors: {
brand: {
primary: 'var(--color-brand-primary)',
secondary: 'var(--color-brand-secondary)',
}
},
// EVITĂ să pui chestii super specifice gen:
// spacing: { 'button-padding-left-custom': '13px' }
}
}
}Am văzut zeci de proiecte blocate în dezbateri sterile despre cum ar trebui să arate clasele de spațiere în Tailwind CSS. Unii vor doar tokens rigizi definiți în config, alții abuzează de parantezele pătrate până când codul arată ca o ciorbă de caractere speciale. Hai să vedem cum găsești echilibrul fără să-ți prinzi urechile și fără să blochezi livrarea.
Capcana parantezelor pătrate (-[...])
Am pățit-o acum un an la o platformă de e-commerce cu vreo 12.000 de useri activi pe zi. Designerul schimba des layout-ul pe parcurs și, din grabă, am început să folosim top-[13px], w-[347px] și bg-[#f3f4f6] direct în componente. Era rapid la început, n-am ce zice.
Problema majoră a apărut când clientul a cerut un audit de UI și implementarea unui dark mode parțial. Când ai 50 de instanțe de text-[15px] împrăștiate în tot proiectul, e aproape imposibil să faci refactoring global fără să spargi ceva în producție. Arbitrary values sunt excelente ca o supapă de siguranță, dar folosite în exces îți distrug complet consistența vizuală și mentenabilitatea.
Când e complet OK să trișezi?
Să fim sinceri, viața de dev nu e ideală și nici designul din Figma nu e mereu aliniat la pixel. Există cazuri clare când vrei și trebuie să ieși din sistemul de design:
- O imagine de fundal pe un landing page de campanie care trebuie poziționată la un procent ciudat:
bg-[position:20%_30%]. - Integrarea unui widget dintr-un script extern (gen un chat de support) care cere o lățime fixă dubioasă, cum ar fi
w-[283px]. - O animație CSS complexă pe care o folosești într-un singur loc din toată aplicația.
Trade-off-ul este simplu. Dacă valoarea respectivă nu se repetă în alte ecrane și nu definește identitatea vizuală a brandului (cum sunt culorile de brand sau marginile standard), folosește arbitrary values fără remușcări. Nu merită să poluezi fișierul tailwind.config.js cu excepții inutile care apar o singură dată în aplicație.
Cum organizăm corect un sistem hibrid
Din experiența mea, cea mai bună cale e să definești în config doar chestiile cu adevărat globale. Nu încerca să creezi tokens pentru absolut orice detaliu micro, pentru că vei ajunge să scrii clase de doi metri lungime în HTML și pierzi fix avantajul vitezei de scriere.
Un config curat ar trebui să definească culorile tematice (folosind nume semantice, nu nuanțe brute), fonturile și eventual 2-3 valori de border-radius specifice brandului. Pentru restul elementelor de layout (padding, margin, gap), scale-ul default din Tailwind (bazat pe rem) este mai mult decât suficient dacă echipa de design folosește o grilă corectă de 4px sau 8px.
La proiectul menționat mai sus, am curățat codul când am trecut la un sistem simplu: culorile și fonturile erau bătute în cuie în config ca design tokens, iar excepțiile de layout le-am lăsat ca arbitrary values, dar documentate în comentarii de cod unde era cazul.
Tu cum abordezi problema în proiectele tale? Ești în tabăra care pune totul în config sau mergi pe ideea că parantezele pătrate îți oferă libertatea de care ai nevoie în viața de zi cu zi?