🧩 Opinionated přístup ke strukturování komponent

Každý projekt začíná nevinně — složka components/, pár základních souborů jako Button.jsx, Header.jsx, Card.jsx… a všechno vypadá přehledně. Jenže po pár měsících (nebo letech) se z té složky stane černá díra. Komponenty mají podobné názvy, někdy dělají skoro totéž, ale přesto jsou jiné. A onboardovat nového vývojáře do takového projektu? Peklo.

Postupem času jsem si začal víc všímat, že struktura komponent není jen otázka estetiky nebo osobní preference. Je to architektonické rozhodnutí, které ovlivňuje škálovatelnost projektu, konzistenci, ale i mentální pohodu celého týmu. Proto jsem si vytvořil svůj vlastní, „opinionated“ systém, který mi už roky pomáhá držet pořádek v projektech, kde komponenty rostou geometrickou řadou.

Proč vůbec řešit strukturu komponent?

Většina článků o architektuře frontend projektů se soustředí na technologie, knihovny, performance nebo build procesy. Ale málokdo řeší, jak vůbec komponenty kategorizovat. A přitom právě tohle rozhoduje o tom, jestli se v projektu dokážeš zorientovat za minutu — nebo za půl dne.

Potřeboval jsem systém, který:

• se dá škálovat – zvládne stovky komponent bez chaosu,
• je čitelný a konzistentní,
• umožňuje rychlý onboarding nových lidí,
• a má jasně definované úrovně zodpovědnosti – co má komponenta dělat a co už ne.

Po několika iteracích jsem si vytvořil přístup, který se mi dlouhodobě osvědčil. Zjednodušeně řečeno – komponenty rozděluju podle úrovně jejich abstrakce a zodpovědnosti.

Můj systém vrstev

Každá komponenta má své místo a jasný účel. Díky tomu se v projektu dá rychle zorientovat, i když ho otevřu po půl roce.

Core – základní stavební kameny

Komponenty, které tvoří úplný základ UI. Mají jasnou funkci, nejsou závislé na žádné konkrétní části projektu a používají se napříč celým kódem.

Button, Link, Img, Modal, Pagination

Můžu je chápat jako čisté, nízkoúrovňové komponenty, které řeší jen svůj vizuál nebo chování, ale nic „nad nimi“. Button neřeší, kde se používá ani jaký má význam v kontextu stránky — prostě jen vykresluje tlačítko.

Bases – základní stavební bloky

Komponenty, které definují určité rozložení nebo standardizovaný vzhled. Něco jako „wrappery“, které drží jednotný styl a chování.

BaseSection, BaseHeader, BaseForm

Jsou to stavební bloky, které drží projekt pohromadě vizuálně i logicky. Všude se chovají stejně, a tím vzniká konzistence napříč webem.

Items – jednotlivé obsahové položky

Item je komponenta, která reprezentuje jednu obsahovou jednotku – například produkt, článek, událost, recenzi, cokoliv.

Item neřeší layout – tedy kolik jich je v řádku, jestli jsou ve slideru nebo v gridu. Jeho jediná zodpovědnost je zobrazit daný obsah správně a samostatně.

Forms – konkrétní sestavy Fieldů

Form už je konkrétní implementace určitého účelu – například kontakt, přihlášení nebo objednávka. Form tedy kombinuje různé Fieldy, ale neměl by obsahovat layout nebo prvky, které se netýkají samotného formuláře. Díky tomu lze Form použít třeba jak na stránce, tak v modalu.

ContactForm, LoginForm, NewsletterForm

Tento přístup dělá formuláře znovupoužitelné a přenositelnější – nemusíš mít pro každé umístění jeho vlastní variantu.

Technologie? Nepodstatné

Celý tento systém není vázaný na konkrétní framework. Používám ho v Twigu, ale stejně dobře by fungoval i v Reactu, Vue, Astru nebo prakticky jakémkoliv templating systému.