Component as a building block - fdnd-task/dont-repeat-yourself-component-library GitHub Wiki

Don't Repeat Yourself

Component as a building block

Over het structureren van componenten met een design system en een standaard in naamgeving.

Aanpak

Je hebt inmiddels een aantal componenten gebouwd (of aangepast) in je project. Maar hoe zorg je ervoor dat je codebase overzichtelijk blijft als het project groeit? Vandaag leer je twee dingen:

Hoe je componenten structureert met een design system
Hoe je naamgeving consistent gebruikt in verschillende talen

1. Design systems

Er zijn verschillende manieren om componenten in te delen. Elk systeem heeft zijn eigen logica en past beter bij bepaalde projecten.

🛠️ Opdracht 1 (30 min)

Doe deze oefening met je tafel.

Zoek online naar manieren om componenten te structureren.

Schrijf per methode op het whiteboard:
- Wat is het idee achter de methode?
- Hoe ziet de mappenstructuur eruit?
- Voor welk type project is het geschikt?
Presenteer kort aan een andere tafel wat je hebt gevonden.

2. Atomic design

Bij FDND hebben we gekozen om het design system van Atomic design in te zetten.

Atomic Design deelt componenten in op abstractieniveau, van klein naar groot:

Niveau	Wat is het	Voorbeelden
Atoms	Kleinste bouwstenen, volledig generiek	`Button.svelte`, `Input.svelte`, `Badge.svelte`, `Icon.svelte`
Molecules	Combinaties van atoms	`SearchBar.svelte`, `FormField.svelte`, `NavItem.svelte`
Organisms	Complexe blokken met context	`Navbar.svelte`, `LoginForm.svelte`, `Card.svelte`
Templates	Pagina-layouts	`+layout.svelte`, `+layout.server.js`
Pages	In SvelteKit: je pagina bestanden	`+page.svelte`, `+page.server.js`

De mappenstructuur in SvelteKit ziet er bijv. zo uit:

src/lib/
  atoms/
    Button.svelte
    Input.svelte
    Badge.svelte
  molecules/
    FormField.svelte
    SearchBar.svelte
  organisms/
    Navbar.svelte
    LoginForm.svelte

src/routes
   +layout.svelte
   +page.svelte

src/routes/blog
   +layout.svelte

src/routes/blog/[slug]
   +page.svelte

🛠️ Opdracht 2 (20 min)

Doe deze oefening met je team.

Bekijk de componenten die er al zijn in het project, ook bestaande projecten kun je valideren.
Maak een lijst: welk component is een atom, molecule of organism?
Herstructureer je components/ map naar de Atomic Design indeling. Schrijf deze op het whiteboard
Schrijf bij componenten waar je over twijfelt een ?, bespreek met een ander team wat zij denken van jouw ?'s
Update je CONTRIBUTING.md met de conventie van Atomic Design

3. Naamgeving

Naast structuur is ook de naamgeving van je CSS-klassen belangrijk. Zonder afspraken krijg je al snel namen als .red-button, .button2 of .nav-iets. Er zijn verschillende methodes om dit te voorkomen.

🛠️ Opdracht 3 (20 min)

Doe deze oefening in je team.

Zoek online naar CSS-naamgevingsconventies.

Schrijf per methode op het whiteboard:
- Wat is het basisprincipe?
- Hoe zien klassenamen eruit?
- Wat is een voor- en nadeel?
Presenteer kort aan een ander team wat je hebt gevonden.

4. Global CSS vs Component CSS

Studenten laten uitzoeken wat hoort nou in de Global en wat hoort nou op component context. Denk aan Modular scale voor typo les van Koop en hieraan toevoegen modular scale voor marge.

🛠️ Opdracht 4 (30 min)

Doe dit met je team.

Loop met je team door de componenten, bekijk welke styling daar naar de global css verhuist kan worden
Bespreek de lijst met een docent.

Extra bronnen

💪 Extra uitdagingen

Zet je atoms en molecules op in Storybook zodat je een eigen component library krijgt
Schrijf een barrel file (index.js) per Atomic Design-laag zodat imports overzichtelijk blijven

✒️ Leervragen

Zet de antwoorden in je learning journal:

Wat is het verschil tussen een atom, molecule en organism? Geef een voorbeeld uit je eigen project.
Waarom is consistente naamgeving belangrijk in een team?
Hoe helpt BEM om CSS overzichtelijk te houden naarmate een project groeit?
Waar liep je tegenaan bij het herstructureren van je componenten, en hoe heb je dat opgelost?