Master $state, $derived, $effect, and $props runes and understand how they replace Svelte 4 stores, reactive statements, and lifecycle patterns.
0 / 5 completed
1 / 5
What is the $state rune in Svelte 5 and how does it replace the old reactive variable syntax?
$state rune: Svelte 5 replaces implicit reactivity (where any let in a component was reactive) with explicit rune syntax. $state works in .svelte files and in .svelte.ts files, enabling shared reactive state outside components. Deep objects become deeply reactive proxies, replacing the need for spread-assignment workarounds.
2 / 5
What does the $derived rune do in Svelte 5?
$derived rune: like computed values in Vue or useMemo in React, $derived tracks which $state values are read during its computation and re-runs only when those change. For complex derivations that cannot be expressed as a single expression, $derived.by(() => { ... }) accepts a function body.
3 / 5
What is the $effect rune used for in Svelte 5?
$effect rune:$effect(() => { const sub = store.subscribe(cb); return () => sub(); }) — the returned function is the cleanup, called before the next run or on component destroy. Unlike Svelte 4's $: blocks, effects do not run during SSR by default and have clear dependency tracking semantics.
4 / 5
How does the $props rune in Svelte 5 replace the export let syntax?
$props rune: in Svelte 4, each prop was a separate export let name. With $props(), all props are destructured at once with defaults: let { title, items = [] }: { title: string; items: string[] } = $props(). The TypeScript generic form $props<{ title: string }>() provides full type safety.
5 / 5
How do Svelte 5 runes replace Svelte stores for cross-component state?
Runes vs stores: Svelte writable stores required $count syntax in templates (the auto-subscription prefix) and manual subscribe/unsubscribe outside components. Runes in .svelte.ts modules export plain reactive values that are imported and used directly — no special template prefix, no manual subscription management.