Core SvelteKit Principles: Runes & Reactivity - fdnd-task/lose-your-head-the-client-case GitHub Wiki

Lose Your Head - The Client Case

Over hoe in SvelteKit websites server-side first worden opgebouwd, en hoe je die vervolgens enhanced met reactivity via runes.

Progressive enhancement helpt de eindgebruiker: die krijgt een website die altijd werkt, ook op een trage verbinding, een oud device, als JavaScript faalt of niet wordt ondersteund.

Progressive enhancement helpt bij na te denken over wat server-side first hoort te gebeuren (forms, data, navigatie, url, etc) en wat vervolgens als enhancement kan worden toegevoegd aan de client.

Aanpak

Jullie onderzoeken hoe bestaande FDND projecten werken met én zonder client-side JavaScript, en passen dat vervolgens toe op jullie eigen project. Dat doen we in twee stappen:

  1. Onderzoek met AI server-side first en Progressive Enhancement in SvelteKit
  2. Server-side first bouwen en vervolgens enhancen met reactivity en runes

1. Onderzoek met AI server-side first & Progressive Ehancement in SvelteKit

SvelteKit is zo ontworpen dat pagina's en formulieren ook zonder client-side JavaScript kunnen werken: navigatie via echte links, formulieren via POST-requests of GET-requests. JavaScript voegt daarna snelheid en interactiviteit toe (client-side routing, optimistic UI, reactivity), maar is niet verplicht om de core functionality te laten werken.

Reactivity in Svelte 5 wordt geregeld met runes (bijvoorbeeld; $props(), $state(), $derived() en $effect()). Reactivity is puur client-side gedrag: het bepaalt hoe de UI reageert ná het laden van client-side JavaScript.

Bij het eigen maken van een framework kan het ingewikkeld zijn grip te krijgen op deze onderliggende principes. Vandaag ga je met je team onderzoek doen naar hoe je met SvelteKit volgens het Progressive Enhancement principe je website server-side first kan opzetten en vervolgens kan enhancen met client-side JavaScript (Reactivity). Hierbij ga je onder andere gebruik maken van large language models (LLM), dit zijn AI-modellen die getraind zijn op een dataset met voorbeelden met als doel waarschijnlijke antwoorden te genereren op basis van een prompt.

Het is belangrijk dat je oefent met prompt engineering. Een eenvoudige prompt geeft simpelweg slechte resultaten, een regel die de opleiding SMP hanteert is: shit in, shit out. Dit past niet bij de kwaliteit die wij nastreven als het gaat om Frontend code! Door het toevoegen van extra context wordt het resultaat stukken beter maar dan nog moet je dingen nalopen op feitelijke correctheid, dit doe je door voorbeelden uit te proberen, op te zoeken of te vergelijken met de officiële SvelteKit documentatie.

Bekijk deze prompt: "Waarom werkt deze filter functie niet zonder JavaScript?" Een zeer eenvoudige prompt waarbij je waarschijnlijk een algemeen, weinig bruikbaar antwoord terugkrijgt. Door het toevoegen van rol oriëntatie, context, beperkingen en acties wordt het resultaat beter.

Bekijk ter vergelijking eens de volgende prompt: "Je bent senior Frontend Developer met een passie voor toegankelijkheid en progressive enhancement. Hieronder staat de code van een filter component in SvelteKit dat items filtert op categorie. Zonder JavaScript werkt het filter niet. Analyseer welke regels code hiervoor verantwoordelijk zijn, leg uit waarom dit gebeurt, en beschrijf hoe dit opgelost kan worden volgens het principe van progressive enhancement, bijvoorbeeld met een querystring en een load functie. [voeg relevante code uit de betreffende repository toe]"

Zie je het verschil? In het tweede voorbeeld is een rol opgenomen (senior frontend developer) met een specifieke voorkeur (passie voor toegankelijkheid en progressive enhancement). Het is specifiek (SvelteKit, filteren op categorie, progressive enhancement) en bevat concrete acties (code analyseren, oorzaak benoemen, oplossing beschrijven).

Nota Bene: het is belangrijk in je achterhoofd te houden dat in feite alles wat een LLM genereert hallucinatie is en dus op feitelijke waarheid gecontroleerd moet worden.

🛠️ Opdracht 1 (60 min)

Bekijk in teams de volgende drie FDND projecten:

  1. Open elke website twee keer: één keer normaal, één keer met JavaScript uitgeschakeld in de browser.
  2. Loop per project de belangrijkste interactieve features na (navigatie, filters, formulieren, zoeken, favorieten/like-knoppen, paginering, modals, etc.) en noteer in een tabel: welke features werken wél en welke niet werken zonder JS.
  3. Zoek, voor de features die het níet doen, met hulp van de AI Chat van de HvA per feature uit waarom (door welke code) het niet werkt, en hoe dit opgelost zou kunnen worden volgens het principe van progressive enhancement.
  4. Schrijf op het whiteboard per feature de wat, waarom en hoe én de bijbehorende prompts op.

2. Server-side first bouwen en vervolgens enhancen met reactivity en runes

Voordat je een component enhanced, ofwel reactief maakt, zorg je ervoor dat het eerst server-side goed werkt. In SvelteKit forceer je dit door client-side rendering (en dus hydration) voor een route uit te zetten:

// +page.server.js
export const csr = false;

Zolang deze regel erin staat, moet de pagina volledig werken op basis van server-rendering en normale form submits. Dit dwingt je om de logica in load(), form actions, en server-side redirects te zetten in plaats van in client-side state.

🛠️ Opdracht 2 (100 min)

  1. Kies uit je eigen project één interactief component, bestaand of nieuw (bijv. een filter, een like-knop, een zoekveld, een formulier, een comment-sectie).
  2. Zet in de bijbehorende route export const csr = false in +page.server.js.
  3. Bouw of herbouw het component zó dat het volledig server-side werkt:
    • Schrijf semantische HTML
    • Schrijf baseline CSS
    • Gebruik een <form> met een action in +page.server.js voor elke POST interactie.
    • Gebruik een <form> met een goto() en URLSearchParams voor elke GET interactie.
    • Laad de benodigde data via load() in +page.server.js of +page.js.
    • Test dit door de pagina te herladen zonder dat er iets stuk gaat: elke actie moet een normale page (re)load triggeren en het juiste resultaat tonen.
  4. Enhance het component eerst met CSS
  5. Werkt het component naar behoren server-side? Verwijder dan export const csr = false en enhance het component stap voor stap:
    • Voeg use:enhance toe aan je <form method="POST"> voor progressive enhancement (voorkomt full page reload, blijft werken als JS faalt).
    • Voeg waar nodig reactivity toe met runes ($state, $derived) voor directe feedback (bijv. optimistic UI, een teller, een toggle-state) zonder dat de server-functionaliteit verloren gaat.
    • Gebruik $effect alleen waar het echt nodig is (bijv. een externe library initialiseren) — niet als vervanging voor load() of form actions.
  6. Noteer in je learning journal: wat deed je component vóór de enhancement (server-only), en wat voegt de JS-laag concreet toe?

Extra bronnen

✒️ Leervragen

Zet de antwoorden in je learning journal:

  1. Wat is progressive enhancement in je eigen woorden, en waarom past dit bij SvelteKit?
  2. Welke van de vijf onderzochte FDND projecten had de meeste problemen zonder JavaScript, en wat was daarvan de technische oorzaak?
  3. Wat is het verschil tussen state die je met runes bijhoudt en state/data die via load() en form actions loopt?
  4. Hoe hielp het bouwen met csr = false je om betere keuzes te maken in je eigen component?
  5. Hoe kan je AI gebruiken om principes en best-practices van een framework te ontdekken?
⚠️ **GitHub.com Fallback** ⚠️