Alle artikelen
Tutorial4 min leestijd · 30 augustus 2026

Voorkom losse eindjes in Lovable met de vier-state promptmethode

Een veelvoorkomend probleem bij het bouwen in Lovable is dat de AI alleen het succes-scenario ontwerpt. Met de vier-state promptmethode dwing je het systeem vanaf de eerste poging om lege schermen, laadstatussen en foutmeldingen mee te nemen.

Sanne de Vries

Bijdrager · lvbl.nl

Voorkom losse eindjes in Lovable met de vier-state promptmethode
Foto: Christopher Gower / Unsplash
Bouwen in Lovable voelt in het begin vaak als magie. Je typt wat je wilt zien, en een paar seconden later staat er een strakke interface. Maar zodra je de app echt gaat testen, stuit je op de bekende tekortkomingen. Wat gebeurt er als de gebruiker nog geen data heeft ingevoerd? Hoe ziet de pagina eruit als een API-verzoek vertraging oploopt? AI-modellen richten zich standaard op het positieve scenario, het zogenaamde happy path. Dit leidt tot applicaties die er fantastisch uitzien in de demonstratie, maar breken zodra ze in een echte omgeving terechtkomen.

De valkuil van het succes-scenario

ontstaat doordat taalmodellen zijn getraind op het snel genereren van zichtbare resultaten. Als je vraagt om een dashboard met een lijst van recente bestellingen, genereert Lovable een tabel gevuld met nette demodata. Dat ziet er leuk uit op het scherm, maar de onderliggende code ontbeert de nodige logica voor randgevallen. Zodra je de database koppelt en er nog geen bestellingen zijn, blijft de tabel leeg of crasht de pagina door een ongedefinieerde variabele. Je moet vervolgens meerdere prompts verspillen om alle vergeten scenario's alsnog toe te voegen.

De vier-state promptmethode

lost dit op door vóór de generatie strak te kaderen welke toestanden het component kan aannemen. Elk UI-element of scherm in een applicatie heeft in de praktijk vier basistoestanden: de lege toestand (empty state), de laadtoestand (loading state), de succesvolle toestand (data state) en de fouttoestand (error state). Door Lovable in één prompt opdracht te geven alle vier de toestanden uit te werken, genereert het AI-model niet alleen de HTML en CSS, maar ook direct de juiste voorwaardelijke weergave in de TypeScript-code.

Het opbouwen van de perfecte prompt

vereist een vaste structuur. Je begint met het benoemen van het hoofddoel van het component, waarna je expliciet de eisen per toestand omschrijft. In plaats van te vragen om een simpel overzicht van projecten, specificeer je precies wat er in elke situatie moet gebeuren op het scherm.

In de praktijk ziet dat er zo uit

wanneer je een nieuw onderdeel aanvraagt: "Bouw een projectenoverzicht met de volgende vier toestanden: 1. Loading: Toon een skeleton loader met drie geanimeerde grijze blokken. 2. Empty: Toon een illustratie of een icon met de tekst 'Nog geen projecten' en een duidelijke knop 'Nieuw project aanmaken'. 3. Data: Toon een grid van kaarten met projectnaam, datum en statusbadge. 4. Error: Toon een rode melding met 'Ophalen mislukt' en een knop 'Opnieuw proberen'. Gebruik React-state om tussen deze toestanden te kunnen schakelen in de preview."

De kracht van expliciete kaders

zit in de manier waarop LLMs code schrijven. Als je de AI dwingt na te denken over het afhandelen van fouten en het laden van gegevens, moet het model van tevoren schonere componenten ontwerpen. Er worden direct state-variabelen aangemaakt, zoals isError, isLoading en een controle op een lege array. Dit voorkomt dat je later spaghetti-code krijgt waarin achteraf nog logica moet worden ingepast. Op lvbl.nl zien we regelmatig dat ontwikkelaars uren kwijt zijn aan het herstellen van rommelige code, simpelweg omdat de eerste prompt te oppervlakkig was ingestoken.

Test direct alle scenario's

door Lovable te vragen een kleine ontwikkelaars-toggle toe te voegen in de interface. Tijdens het bouwen in het platform wil je direct zien hoe het lege scherm eruitziet zonder dat je daarvoor de database hoeft te legen. Geef in je prompt de instructie mee dat er onderin het scherm tijdelijk vier knoppen mogen staan waarmee je handmatig kunt wisselen tussen 'loading', 'empty', 'data' en 'error'. Hierdoor kun je de styling van alle situaties meteen controleren en verfijnen. Zodra de interface klopt, vraag je Lovable om de testknoppen te verwijderen en het component aan de echte databron te koppelen.

Minder prompts, betere code

is de uiteindelijke winst van deze werkwijze. Veel makers die beginnen met vibe coding raken gefrustreerd doordat de AI bij de vijfde aanpassing eerdere functionaliteit weer sloopt. Hoe meer prompts je nodig hebt voor één onderdeel, hoe groter de kans op regressie in het project. Door de vier toestanden in één keer goed neer te zetten, bespaar je tokens, tijd en voorkom je onnodige vervuiling van de codebase.

Maak van de vier-state methode een gewoonte

bij elk nieuw onderdeel dat je toevoegt aan je Lovable-project. Of het nu gaat om een formulier, een tabel, een profielpagina of een instellingenscherm: denk altijd vanuit de vier toestanden voordat je op de verzendknop drukt. Het kost je dertig seconden extra bij het typewerk, maar het levert je een strakke, robuuste applicatie op die direct klaar is voor echte gebruikers.

Vond je dit fijn?

Geef een hartje en deel het met een andere Lovable-fan.

Ook interessant

Alle artikelen