---
"@type": TechArticle
"@id": "https://hallobraaf.nl/artikelen/upload-chunks"
"@source": "https://hallobraaf.nl/data/techarticle/upload-chunks.json"
"@stamp": "2026-10-13T12:53:52+00:00"
articleSection: UX/UI
author: {"@id":"https://hallobraaf.nl/#joey"}
dateModified: "2026-08-11T00:00:00+02:00"
datePublished: "2026-08-11T00:00:00+02:00"
description: "Grote bestanden uploaden zonder dat één hapering alles omgooit: chunked uploads met zichtbare voortgang, pauze, retry met backoff en een wachtrij van reepjes."
genre: Patroon
headline: Upload-strips met chunks
identifier: upload-chunks
inLanguage: nl
keywords: ["UX/UI","upload"]
publisher: {"@id":"https://hallobraaf.nl/#organization"}
url: "https://hallobraaf.nl/artikelen/upload-chunks"
workExample:
  "@type": WebApplication
  name: Demo — upload-strips met chunks
  url: "https://hallobraaf.nl/assets/demos/upload-chunks.html"
---

# Upload-strips met chunks

Een upload van 200MB over een haperende verbinding is gedoemd als je 'm in één request verstuurt: bij 94% valt de wifi weg en mag je gebruiker opnieuw beginnen. Het patroon hierboven knipt elk bestand in chunks en maakt van de upload een rij kleine, herstelbare stappen — met een interface die eerlijk vertelt waar hij mee bezig is.

## De rail: init → chunk×N → finalize

Elke upload volgt dezelfde rail. Een *init*-aanroep meldt het bestand aan bij de server, daarna gaan de chunks er sequentieel doorheen, en een *finalize* plakt ze server-side aan elkaar. In de demo zijn die stappen gesimuleerd, maar de vorm is precies wat je tegen een echte chunked-upload-API (eigen endpoint, S3 multipart, tus) aan zet.

Sequentieel, niet parallel — bewust. Parallelle chunks zijn sneller op een goede verbinding, maar maken pauzeren, hervatten en foutafhandeling een orde ingewikkelder. Voor de meeste toepassingen wint de eenvoud.

## Falen is een normale stap

In de demo faalt ±10% van de chunks expres. Elke mislukte chunk krijgt maximaal drie nieuwe pogingen met exponentiële backoff — 600ms, dan 1,2s, dan 2,4s — en de gebruiker *ziet* dat: "Connection lost — retrying (2/3)…". Pas als de pogingen op zijn wordt het een echte error, met een retry-knop die het bestand gewoon opnieuw in de wachtrij zet. Omdat alleen de mislukte chunk opnieuw gaat, is een retry bijna gratis.

## States als contract

Elke reep is op elk moment in precies één van vijf states, als class op het element: `is-queued`, `is-uploading`, `is-paused`, `is-completed`, `is-error`. De CSS kiest per state welke actieknoppen überhaupt bestaan — pauze alleen tijdens uploaden, hervatten alleen bij pauze, retry alleen bij een fout. Geen `disabled`-knoppen die niks doen: wat er niet toe doet, is er niet.

De voortgang zelf is één custom property. JS zet `--p` op de reep; een pseudo-element vult tot die breedte. De DOM blijft rustig, er wordt niks her-gerenderd — er verandert alleen een getal.

## Pauze die z'n woord houdt

Pauzeren onderbreekt nooit een lopende chunk — het zet een vlag, en tussen twee chunks in stopt de upload netjes. Daardoor is de voortgang die je ziet ook écht veiliggesteld. Hervatten zet het bestand vooraan de wachtrij: wat de gebruiker bewust heeft hervat, gaat vóór werk dat nog moet beginnen.

## Wanneer dit patroon

Overal waar uploads groter zijn dan een vakantiefoto of verbindingen slechter dan glasvezel: portalen waar klanten drukwerk-bestanden aanleveren, media-bibliotheken, formulieren met bijlagen op mobiel. De demo is klein gehouden — geen framework, geen dependencies — zodat de mechaniek het verhaal is.