TK1 - kokjp1/TechTrack GitHub Wiki

Codebase Structuur

🔧 Technische onderbouwing van mijn repo-structuur

(Waarom mijn indeling bewuster, schoner en meer schaalbaar is dan de standaard SvelteKit indeling)

Mijn project gebruikt SvelteKit, maar in plaats van te vertrouwen op de minimale standaardindeling die SvelteKit aanbiedt, heb ik mijn hele codebase opgesplitst volgens een duidelijk gelaagd atomisch model.

Mijn structuur houdt de grote verantwoordelijkheden volledig uit elkaar:

1. Authorisiation & API-logica

Alle Spotify-authenticatie, fetches, transformaties en netwerkcode leven buiten de routes. Daardoor is mijn "backend" duidelijk gescheiden van de frontend, door het niet allemaal onder "routes" te zetten. Routes hoeven niet zelf te weten hoe data binnenkomt.

2. State management & Data Opslag

In plaats van route-gebonden state en states in componenten zelf zetten gebruik ik app-wide stores als tussenlaag. Hierdoor blijft de state losgekoppeld van de UI en van de navigatie. Dit is veel cleaner dan de standaard SvelteKit-aanpak waarbij state in verschillende routes verspreid raakt.

Daarnaast centraliseer ik ook het opgehaalde/verwerkte data object van de Spotify API dat ik fetch. Hierdoor is het in elk bestand hetzelfde, up-to-date en beschikbaar.

3. Presentatielaag (UI + visualisaties)

Componenten zijn puur visueel: ze renderen data, maar beheren het niet. Ook D3-code is duidelijk gescheiden van dataverwerking. Dit voorkomt dat complexe visualisatiecode gemixed raakt met fetches of applicatielogica.

Wat maakt dit “beter” dan de standaard aanpak?

Geen duplicate logica alles zit op een centrale plek.
Mijn componenten zijn klein en doelgericht, zo min mogelijk lang regelige bestanden.
De structuur schaalt automatisch mee als je extra visualisaties, endpoints of state toevoegt.
SSR problemen worden voorkomen (o.a. via Onmount en if(!browser)) door deze projectstructuur
En tot slot; Routes blijven Routes. +page.svelte, blijft een PAGE. Je gebruik de page.svelte om de UI op te bouwen adhv componenten die reactief veranderen en uitgewisseld kunnen worden wanneer nodig.