Library-architectuur

De JavaScript-library is opgebouwd rond één eenvoudige regel:

Deel wat echt herbruikbaar is. Houd formulier-specifieke logica geïsoleerd.

Repositorystructuur

Een opgeschoonde weergave van de projectstructuur:

/
├── loader.js
├── manifest.json
├── forms/
│   ├── FORM_001.js
│   ├── FORM_002.js
│   ├── FORM_003.js
│   └── ...
├── shared/
│   ├── functions.js
│   └── timing.js
└── homepages/
    └── Homepage.js

Verantwoordelijkheid per laag

Laag	Verantwoordelijkheid
loader.js	Detecteert de actieve Planon-context en laadt de juiste scripts
shared/functions.js	Herbruikbare utilities voor meerdere formulieren
shared/timing.js	Helpers voor elementen die asynchroon renderen
forms/*.js	Formulier-specifieke logica
homepages/*.js	Homepage-specifiek gedrag
manifest.json	Metadata / geregistreerde modules van de library

Waarom geen gigantisch bestand?

Eén groot JavaScript-bestand zou alle formulieren afhankelijk maken van hetzelfde implementatie-oppervlak.

In plaats daarvan:

                     ┌──────────────────┐
                     │   shared-laag    │
                     └────────┬─────────┘
                              │
              ┌───────────────┼───────────────┐
              ▼               ▼               ▼
        ┌──────────┐    ┌──────────┐    ┌──────────┐
        │ FORM_001 │    │ FORM_002 │    │ FORM_003 │
        └──────────┘    └──────────┘    └──────────┘

Elk formulier krijgt toegang tot gedeeld gedrag zonder zijn eigen grens te verliezen.

Engineering trade-off

Ik heb bewust voorkomen dat de shared-laag een groot framework werd.

De shared-laag bevat alleen gedrag dat echt hergebruikt wordt. Business-specifieke logica blijft bij het formulier dat ervoor verantwoordelijk is.