This page intends to give a broad overview of how code written using the new APIs looks compared to code not using them. You will see that for most simple tasks that only involve a single component it will actually not look much different. For more complex logic, they simplify things.
Counterpermalink
The $state, $derived and $effect runes replace magic let declarations, $: x = ... and $: { ... }. Event handlers can be written as event attributes now, which in practise means just removing the colon.
<script>
let count = 0;
$: double = count * 2;
$: {
let count = $state(0);
let double = $derived(count * 2);
$effect(() => {
if (count > 10) {
alert('Too high!');
}
}
});
</script>
<button on:click={() => count++}>
<button onclick={() => count++}>
{count} / {double}
</button>
Tracking dependenciespermalink
In non-runes mode, dependencies of $: statements are tracked at compile time. a and b changing will only cause sum to be recalculated because the expression — add(a, b) — refers to those values.
In runes mode, dependencies are tracked at run time. sum will be recalculated whenever a or b change, whether they are passed in to the add function or accessed via closure. This results in more maintainable, refactorable code.
<script>
let a = 0;
let b = 0;
$: sum = add(a, b);
let a = $state(0);
let b = $state(0);
let sum = $derived(add());
function add(a, b) {
function add() {
return a + b;
}
</script>
<button on:click={() => a++}>a++</button>
<button on:click={() => b++}>b++</button>
<button onclick={() => a++}>a++</button>
<button onclick={() => b++}>b++</button>
<p>{a} + {b} = {sum}</p>
Untracking dependenciespermalink
Conversely, suppose you — for some reason — wanted to recalculate sum when a changes, but not when b changes.
In non-runes mode, we 'hide' the dependency from the compiler by excluding it from the $: statement. In runes mode, we have a better and more explicit solution: untrack.
<script>
import { untrack } from 'svelte';
let a = 0;
let b = 0;
$: sum = add(a);
let a = $state(0);
let b = $state(0);
let sum = $derived(add());
function add(a) {
return a + b;
function add() {
return a + untrack(() => b);
}
</script>
<button on:click={() => a++}>a++</button>
<button on:click={() => b++}>b++</button>
<button onclick={() => a++}>a++</button>
<button onclick={() => b++}>b++</button>
<p>{a} + {b} = {sum}</p>
Simple component propspermalink
<script>
export let count = 0;
let { count = 0 } = $props();
</script>
{count}
Advanced component propspermalink
<script>
let classname = '';
export { classname as class };
let { class: classname, ...others } = $props();
</script>
<pre class={classname}>
{JSON.stringify($$restProps)}
{JSON.stringify(others)}
</pre>
Autoscrollpermalink
To implement a chat window that autoscrolls to the bottom when new messages appear (but only if you were already scrolled to the bottom), we need to measure the DOM before we update it.
In Svelte 4, we do this with beforeUpdate, but this is a flawed approach — it fires before every update, whether it's relevant or not. In the example below, we need to introduce checks like updatingMessages to make sure we don't mess with the scroll position when someone toggles dark mode.
With runes, we can use $effect.pre, which behaves the same as $effect but runs before the DOM is updated. As long as we explicitly reference messages inside the effect body, it will run whenever messages changes, but not when theme changes.
beforeUpdate, and its equally troublesome counterpart afterUpdate, will be deprecated in Svelte 5.
<script>
import { beforeUpdate, afterUpdate, tick } from 'svelte';
import { tick } from 'svelte';
let updatingMessages = false;
let theme = 'dark';
let messages = [];
let theme = $state('dark');
let messages = $state([]);
let viewport;
beforeUpdate(() => {
$effect.pre(() => {
if (!updatingMessages) return;
messages;
const autoscroll = viewport && viewport.offsetHeight + viewport.scrollTop > viewport.scrollHeight - 50;
if (autoscroll) {
tick().then(() => {
viewport.scrollTo(0, viewport.scrollHeight);
});
}
updatingMessages = false;
});
function handleKeydown(event) {
if (event.key === 'Enter') {
const text = event.target.value;
if (!text) return;
updatingMessages = true;
messages = [...messages, text];
event.target.value = '';
}
}
function toggle() {
toggleValue = !toggleValue;
}
</script>
<div class:dark={theme === 'dark'}>
<div bind:this={viewport}>
{#each messages as message}
<p>{message}</p>
{/each}
</div>
<input on:keydown={handleKeydown} />
<input onkeydown={handleKeydown} />
<button on:click={toggle}>
<button onclick={toggle}>
Toggle dark mode
</button>
</div>
Forwarding eventspermalink
Because event handlers are just regular attributes now, the "forwarding events" concept is replaced with just passing callback props. Before, you would have to mark every event that you want to forward separately. You can still do this with event attributes...
<script>
let { onclick, onkeydown, ...attributes } = $props();
</script>
<button
{...$$props}
{...attributes}
on:click
on:keydown
{onclick}
{onkeydown}
>a button</button>
...but in practise what you probably really want to do in these situations is forward all events. This wasn't possible before, but it is now:
<script>
let { ...props } = $props();
</script>
<button
{...$$props}
on:click
on:keydown
{...props}
>a button</button>
Passing UI content to a componentpermalink
Previously, you would pass UI content into components using slots. Svelte 5 provides a better mechanism for this, snippets. In the simple case of passing something to the default slot, nothing has changed for the consumer:
<!-- same with both slots and snippets -->
<script>
import Button from './Button.svelte';
</script>
<Button>click me</Button>Inside Button.svelte, use @render instead of the <slot> tag. The default content is passed as the children prop:
<script>
let { children } = $props();
</script>
<button>
<slot />
{@render children()}
</button>
When passing props back up to the consumer, snippets make things easier to reason about, removing the need to deal with the confusing semantics of the let:-directive:
<!-- provider -->
<script>
let { children } = $props();
</script>
<button>
<slot prop="some value" />
{@render children("some value")}
</button>
<!-- consumer -->
<script>
import Button from './Button.svelte';
</script>
<Button let:prop>click {prop}</Button>
<Button>
{#snippet children(prop)}
click {prop}
{/snippet}
</Button>
Combined with event attributes, this reduces the number of concepts to learn — everything related to the component boundary can now be expressed through props.
When using custom elements, you should still use
<slot />like before. In a future version, when Svelte removes its internal version of slots, it will leave those slots as-is, i.e. output a regular DOM tag instead of transforming it.