Onderzoek naar mappenstructuur


Feature-first

Een (ongeveer) voorbeeld van een feature-first structuur, met een duidelijke scheiding van verantwoordelijkheden tussen technische infrastructuur, businesslogica en de gebruikersinterface. Het doel is om schaalbaarheid, onderhoudbaarheid en lage koppeling te garanderen.

N.B.: er is een core map toegevoegd om te voorkomen dat shared een verzamelmap wordt.

Feature-first structuur

core vs shared

Eenvoudige vuistregel:

Als ik deze map verwijder, stort de hele app dan in?

  • Ja core
  • Nee, maar ik zou code opnieuw moeten schrijven shared

Legt het een manier van werken op aan features?

  • Ja core
  • Nee, het is gewoon een handig hulpmiddel shared

pages vs features

✅ Wat pages/* WEL mag bevatten

  • Ophalen van route-parameters (router.query, getServerSideProps)
  • Keuze van de layout
  • Samenstellen van componenten
  • Doorgeven van props
  • Beslissen “welk scherm wordt weergegeven”

❌ Wat pages/* NIET mag bevatten

  • Businesslogica features
  • Applicatie-hooks (use cases) features
  • DTO → FormType mapping features
  • Complexe orkestratie (workflows) features
  • Directe calls naar React Query of data-access features

Interne structuur van features/my-feature

Een feature map is een businessgerichte UI-module, onafhankelijk van routing, die coherente bouwstenen aanbiedt om één of meerdere pagina’s op te bouwen.

⚠️ Geen afhankelijkheid van routing (geen router.query) Moet via props worden doorgegeven vanuit /pages

1. Screens

Entry point van de business UI.


features/orders/
├── order-overview/
├── create-order/

Bevat:

  • UI-compositie specifiek voor een businessdoel
  • Aanroepen van applicatie-hooks (controllers)

2. Components (pure en herbruikbare UI)


features/orders/
├── OrdersTable.tsx
├── OrderFilters.tsx

Bevat:

  • JSX
  • props
  • callbacks
  • geen React Query
  • geen businesslogica

❌ Wat een feature map NIET mag bevatten

  • Een spiegelstructuur van pages/: dit creëert koppeling met routing
  • Directe toegang tot de router: routing is infrastructuur pages/
  • Globale layoutlogica: buiten de scope van de feature
  • Globale providers: moeten op applicatieniveau staan

Layoutbeheer

Kernprincipe

Een layout is een UI-compositiebeslissing, geen businessbeslissing.

Het beschrijft hoe iets wordt weergegeven, niet wat er gebeurt.

Types layouts en waar ze thuishoren


1. Pagina (route) layout

  • Omvat de volledige pagina
  • Wordt bepaald door routing

📍 In pages/

  • Globaal direct in _app.tsx, of UI extraheren naar layouts/defaultLayout.tsx als het bestand te groot wordt en de leesbaarheid vermindert
  • Gedeeld contextueel shared/components/layouts/

2. Gedeelde layout (niet-business)

  • Gebruikt door meerdere pagina’s
  • Onafhankelijk van businessdomeinen

📍 shared/components/layouts/

Voorbeelden: EditorLayout, DashboardLayout, FullWidthLayout, CenteredLayout, ...

3. Sub-layout (gedeeltelijke layout)


a) Business
  • Structureert een UI-sectie gekoppeld aan een domein
  • Herbruikbaar in meerdere screens

📍 features/*/

b) Generiek
  • Herbruikbare UI-structuur
  • Geen link met business

📍 shared/components/layouts/

Wat je NIET moet doen

  • ❌ Layout in een feature plaatsen als die door de route wordt bepaald
  • ❌ Business layout in shared/ plaatsen

Snelle regel

De route kiest de layout

De feature levert de business UI Business sub-layouts blijven binnen de feature