Design systems cu Shadcn si Tailwind: scalare la 100+ componente
Shadcn UI a schimbat felul in care echipele construiesc design systems in React. In loc sa imporpi o librarie monolitica, copiezi componente in propriul repo si le adaptezi. Combinatia cu Tailwind si Radix te lasa sa pornesti rapid, sa pastrezi controlul total si sa eviti datoria tehnica acumulata de librariile mari. Pe primele zece-douazeci de componente totul pare simplu si flexibil.
Problemele apar la scara. Dupa sase luni de productie, ai usor peste 100 de componente, fiecare cu trei pana la zece variante, theming light si dark, suport multi-brand, traduceri si pattern-uri de accesibilitate diferite. Daca nu impui de la inceput o structura clara de variant system, design tokens si guvernanta, design system-ul devine o jungla in care fiecare developer reinventeaza butonul.
Echipa Blackbone construieste design systems la scara pentru clienti enterprise si SaaS-uri proprii. Articolul de fata distileaza ce functioneaza si ce nu in 2026 cand pleci de la shadcn si vrei sa ajungi la o platforma cu 100 plus componente, doua-trei brand-uri si zeci de developeri care contribuie zilnic.
01De ce shadcn este punctul de plecare ideal
Shadcn nu este o librarie de componente in sensul clasic. Este un set de retete bazate pe Radix Primitives si Tailwind, livrate prin CLI direct in codul tau. Asta inseamna ca nu ai un node_modules cu sute de componente cu API-uri pe care nu le controlezi. Ai cod TypeScript si JSX in propriul repo, pe care il poti modifica oricum vrei.
Avantajele se vad rapid: primitives accesibile, stilizare consistenta cu Tailwind, zero runtime overhead pentru styling si o curba de invatare scurta. Dezavantajele apar cand multi developeri incep sa adauge variante ad-hoc fara o convenție clara. Fiecare buton nou primeste props diferite si in scurt timp ai cinci feluri de a face acelasi lucru.
Firma de IT Blackbone foloseste shadcn ca fundatie in aproape toate proiectele moderne, dar peste el adauga un strat de structura: tokens centralizate, conventii de variant naming, audit periodic si un proces de adaugare a componentelor noi. Fara acest strat, scalezi haosul, nu sistemul.
02Variant system curat cu CVA si tipare predictibile
Class Variance Authority sau, mai recent, tailwind-variants, este coloana vertebrala a oricarui buton serios. Defineste varianta vizuala intr-un singur loc, expune un tip strict catre TypeScript si genereaza string-ul de clase. Cheia este sa stabilesti un set fix de axe pe care toate componentele le respecta: variant, size, tone, density, state.
Daca toate componentele tale au aceeasi structura de variante, developerii nu mai trebuie sa ghiceasca. Un Button are variant primary, secondary, ghost, destructive. Un Badge are exact aceleasi variante. Un Alert la fel. Cand ai 100 de componente, aceasta consistenta valoreaza mai mult decat orice documentatie scrisa, pentru ca devine intuitia echipei.
Echipa Blackbone foloseste un schelet generic exportat ca utility: definesti baseClasses si variants intr-o forma declarativa, iar componenta devine doar un wrapper subtire peste primitive Radix. Codul componentei scade la 30-40 de linii, iar variantele se gestioneaza intr-un singur fisier audibil.
- →Axe fixe: variant, size, tone, density, state
- →Acelasi vocabular pentru toate componentele
- →TypeScript strict pe variant names, nu string-uri libere
- →Defaults explicite pentru a evita ambiguitatea
- →Compound variants documentate, nu ascunse in cod
03Theming cu CSS variables si scopuri multi-brand
Cand ajungi la doua sau trei brand-uri, hardcoding-ul culorilor in clase Tailwind te omoara. Solutia eleganta este sa folosesti variabile CSS la nivel de tokens semantice si sa lasi Tailwind sa le consume prin theme extend. Definesti --background, --foreground, --primary, --primary-foreground, --muted si tot ce ai nevoie ca culori semantice, nu ca valori brute.
Apoi schimbarea de tema sau de brand devine un swap de root variables. Light si dark se rezolva cu prefers-color-scheme sau cu o clasa data-theme pe root. Multi-brand se rezolva cu o clasa suplimentara data-brand. Componentele raman complet ignorante in privinta brand-ului concret, ele cer doar primary si stiu ca obtin ce trebuie.
Pentru produse cum este AxV Store, parte din ecosistemul Blackbone, theming-ul prin CSS variables a permis livrarea unui dark mode complet, a doua palete pentru subbrand si tranzitii intre teme fara sa modifici o singura componenta. Investitia in tokens semantice se intoarce de zece ori la prima cerere de redesign sau rebrand.
Nu folosi --gray-500 in componente. Foloseste --muted-foreground. Cand schimbi paleta, schimbi un singur fisier, nu 100 de componente.
04Accessibility de la baza, nu ca patch ulterior
Radix Primitives, fundamentul shadcn-ului, rezolva 80 la suta din problemele de accesibilitate gratuit: focus management, ARIA roles, keyboard navigation, dismissal logic. Restul de 20 la suta cad pe echipa. Contrast suficient pe ambele teme, focus visible pe toate elementele interactive, etichete clare pentru screen readers, suport pentru reduced motion.
Auditul accessibilitatii nu se face manual o data pe an, ci se automatizeaza in CI cu axe-core sau Pa11y rulat pe Storybook stories. Fiecare componenta noua are stories cu toate variantele si un test de accesibilitate care ruleaza la fiecare PR. Asa nu mai ai surprize si echipa primeste feedback in cateva minute, nu in saptamani.
Firma de IT Blackbone livreaza design systems care trec audituri WCAG 2.2 AA pentru clienti din zone reglementate. Aceasta nu este magie, este disciplina aplicata constant: tokens cu contrast verificat, focus rings vizibile pe orice fundal, tranzitii respectuoase pentru utilizatorii cu vestibular disorders si traduceri ARIA pentru fluxuri non-evidente.
05Design tokens si sincronizare cu Figma
Decuplarea tokens de codul React permite un workflow real cu designerii. Folosesti Style Dictionary, Tokens Studio sau un format propriu JSON. Tokens-urile sunt sursa de adevar si genereaza CSS variables, configuratie Tailwind si tema Figma in acelasi timp. Schimbi o culoare in JSON, build-ul actualizeaza si codul, si design system-ul vizual.
Tokens Studio in Figma este alegerea pragmatica in 2026. Designerii lucreaza vizual, fac push catre un Git repo, build-ul ruleaza si update-ul ajunge in cod ca un PR normal. Inversul functioneaza la fel: un developer poate ajusta un token, iar designerii il vad imediat in Figma. Bridge-ul elimina zile de munca duplicata si decalaje saptamanale.
Echipa Blackbone configureaza acest pipeline de la inceputul proiectului. Mai mult, structuram tokens-urile pe trei niveluri: primitive (culori brute, scale numerice), semantice (background, foreground, primary) si componente (button-primary-bg, card-border). Asa fiecare strat are responsabilitati clare si modificarile la nivel inferior nu sparg componentele.
- →Tokens in trei straturi: primitive, semantice, componente
- →Sursa de adevar in JSON, generare CSS si TS automata
- →Tokens Studio pentru sync bidirectional cu Figma
- →PR automat la fiecare modificare semnificativa
- →Audit de contrast in build, nu manual
06Guvernanta, documentatie si ritualuri de echipa
Un design system la scara are nevoie de oameni dedicati. Nu trebuie sa fie o echipa de zece, pot fi doi-trei core maintainers care revizuiesc contributiile si fac release-uri saptamanale. Fara core maintainers, design system-ul devine un free-for-all unde fiecare echipa adauga ce vrea si calitatea scade rapid.
Documentatia traieste in Storybook sau in Ladle pentru o experienta mai usoara. Fiecare componenta are pagina cu exemple, props documentate, code snippets si linkuri catre componenta Figma corespunzatoare. Documentatia nu este optionala: o componenta fara documentatie nu intra in design system. Aceasta regula simpla mentine calitatea peste ani.
Echipa Blackbone foloseste un ritual saptamanal de sync intre design si engineering, plus un changelog public pentru toate componentele. Versionarea urmeaza SemVer si breaking changes sunt anuntate cu sapte zile inainte. Aceasta predictibilitate face ca echipele consumer sa aiba incredere in design system si sa-l adopte fara frica.
Concluzii
Un design system cu shadcn si Tailwind la scara nu este o problema de tehnologie, este o problema de disciplina. Tools-urile sunt deja excelente. Ce face diferenta este structura impusa de la inceput: variant system unitar, tokens semantice in CSS variables, accessibility automatizata si tokens partajati cu Figma printr-un pipeline real.
Cand acestea sunt la locul lor, sa treci de la 20 la 100 plus componente devine un exercitiu de iteratie, nu un cosmar de refactoring. Echipa Blackbone construieste astfel de design systems pentru clienti care vor sa scaleze frumos. Daca pornesti acum, alege fundatia corecta din ziua unu.
Construim design system-ul tau
Echipa Blackbone livreaza design systems cu shadcn, Tailwind si tokens partajate cu Figma. De la audit la productie, in maxim opt saptamani.
Discută cu Blackbone