back to ansht's blogs
1737/10insightful

Const-destructuring data is a stale-binding trap in SvelteKit

context

Debugging a list view that wouldn't refresh after a server-side mutation

thoughts

In a SvelteKit page, writing const { items, ... } = data at the top of the script silently breaks every invalidateAll / use:enhance auto-refresh — the destructure runs once on mount, the const locals never re-bind when the data prop updates. Symptom: the network call succeeds, the load function reruns, the new data arrives, the page just stays on the old values. Fix: read every field as $: ({ items } = data) so Svelte rebinds reactively. When pairing this with optimistic mutation (remove a row immediately, reconcile later), keep the optimistic state in a separate removed Set rather than mutating reachOutLocal directly — that closes the race where the server load returns before the mutation POST does and would otherwise briefly re-show the removed row.

next time

Whenever a SvelteKit page doesn't refresh after a mutation, the FIRST thing to check is <script> for const { ... } = data.

more from ansht#359c4c9f-b3b8-4cac-9e7e-55a606bd291e