// tailwind.config.js
module.exports = {
theme: {
extend: {
colors: {
brand: {
primary: '#0F172A', // Token clar pentru brand
accent: '#3B82F6',
}
},
spacing: {
'safe-bottom': 'env(safe-area-inset-bottom)',
}
}
}
}Salutare! Văd tot mai des în pull request-uri o luptă surdă între puriștii design system-ului și pragmaticii care vor doar să livreze repede o pagină. Discuția e simplă: când definim un token în tailwind.config.js și când ne băgăm picioarele și scriem un h-[412px] direct în clasă?
Am pățit-o acum un an la un SaaS destul de mărișor, pe la 12k utilizatori activi lunar. Am lăsat echipa de frontend liberă la arbitrare. După trei luni, aveam în codebase vreo 40 de nuanțe diferite de gri și vreo 15 înălțimi ciudate scrise cu top-[13px] sau w-[89%]. A fost un coșmar la refactoring când clientul a cerut un rebranding rapid.
Când e OK să folosești arbitrary values (-[...])
Hai să fim sinceri: nu totul merită un token. Dacă ai o animație custom pe o singură pagină de tip landing page sau un background specific pentru o campanie temporară, n-are sens să poluezi configurarea globală a proiectului.
Arbitrary values sunt geniale pentru:
- Poziționări absolute ultra-specifice (un tooltip care trebuie să stea exact la
top-[-7px]). - Grid-uri atipice pe care le folosești o singură dată (de exemplu,
grid-cols-[1fr_250px_1fr]). - Integrarea rapidă a unor asset-uri externe unde dimensiunile sunt fixe și dictate de un SVG dubios.
Trade-off-ul e evident. Scrii repede, dar pierzi complet controlul centralizat. Dacă designerul se răzgândește și schimbă rotunjimea colțurilor de la 12px la 16px peste tot, iar tu ai folosit rounded-[12px] în 50 de fișiere, ai de dat multe search & replace-uri cu strângere de inimă.
Când TREBUIE să definești un design token în config
Regula mea de aur e simplă: dacă vezi aceeași valoare de trei ori în ecrane diferite, e timpul să o muți în config.
Culorile de brand (primary, secondary, alert), fonturile, spațierile standard (dacă lucrați pe un grid de 4px/8px) și umbrele (shadows) trebuie să fie tokens. Punct. Asta îți oferă un singur punct de adevăr. Am economisit cam 30% din timpul de dezvoltare la al doilea proiect mare doar pentru că am bătut în cuie aceste reguli de la început.
Dacă designerul tău vine cu o culoare nouă care nu e în paletă, nu o adăuga direct în config sub numele blue-slightly-darker. Pune-o ca arbitrary value temporar și mergi la el să-l întrebi dacă e o scăpare sau o decizie conștientă de design.
Cum gestionați asta în echipele voastre? Impuneți reguli stricte în linter sau mergeți pe bunul simț al fiecărui developer?