$$slots is only available in legacy mode
The $$slots object is a legacy mode feature. In runes mode, snippets are used instead, and you can determine which snippets were provided to a component because they are just normal props.
Svelte · Language · all subjects
core/legacy
34 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.
<svelte:fragment> obsolete in Svelte 5
In Svelte 5 and later, the <svelte:fragment> element is obsolete because snippets do not create a wrapping element, making this pattern unnecessary.
<svelte:fragment> legacy element
In Svelte 4 and earlier, <svelte:fragment> allows you to place content in a named slot without wrapping it in a container DOM element, keeping the flow layout of the document intact.
<svelte:fragment> with named slots example
To use <svelte:fragment> in Svelte 4, wrap multiple elements with <svelte:fragment slot="name"> to place them in a named slot without a container element. For example: <svelte:fragment slot="footer"><p>Text 1</p><p>Text 2</p></svelte:fragment>
svelte:component replaced by dynamic import in runes mode
In Svelte 5 runes mode, <svelte:component> is no longer necessary. Dynamic components now work with <MyComponent> directly, which re-renders when the component reference changes.
svelte:component in legacy mode
In legacy mode, svelte:component destroys and recreates the component instance when the value of its this expression changes. The syntax is <svelte:component this={MyComponent} />. If the this prop is falsy, no component is rendered.
Component re-rendering difference between runes and legacy mode
In runes mode, <MyComponent> will re-render if the value of MyComponent changes. In legacy mode, it will not—svelte:component must be used instead to handle component instance changes.
svelte:self legacy element for recursive components
The <svelte:self> element allows a component to include itself recursively. It cannot appear at the top level of markup; it must be inside an if or each block or passed to a component's slot to prevent infinite loops.
svelte:self obsolete - use self-import instead
The <svelte:self> concept is obsolete in Svelte 5. Components can now import themselves directly: import Self from './App.svelte' and then use <Self> instead of <svelte:self> in the same recursive pattern.
svelte:self recursive example with countdown
A component using <svelte:self> to count down: export let count inside <script>, then in markup use {#if count > 0} to show <p>counting down... {count}</p> followed by <svelte:self count={count - 1} />, with an {:else} block showing <p>lift-off!</p> when count reaches 0.
Legacy APIs documentation location
Legacy APIs documentation is generated automatically by a script located at apps/svelte.dev/scripts/sync-docs/index.ts. This file should not be edited manually as it is auto-generated.
Component property accessors in Svelte 3/4
If a component is compiled with `accessors: true`, each instance will have getters and setters for each prop. Setting a value causes synchronous update (unlike `$set` which is asynchronous). By default `accessors` is `false` unless compiling as a custom element. In Svelte 5+, this concept is obsolete; export properties to make them accessible from outside.
Svelte 3/4 component instantiation syntax
In Svelte 3 and 4, client-side components compiled with `generate: 'dom'` are JavaScript classes instantiated with `new Component(options)`. Svelte 5 uses a different API.
Svelte 3/4 component constructor options
Component constructor accepts the following options: `target` (HTMLElement or ShadowRoot, required), `anchor` (null by default, child of target to render before), `props` ({} by default, object of properties), `context` (new Map() by default, root-level context key-value pairs), `hydrate` (false by default, upgrade existing DOM), `intro` (false by default, play transitions on initial render).
Svelte 3/4 hydrate option behavior
The `hydrate: true` option instructs Svelte to upgrade existing DOM from server-side rendering rather than creating new elements. It requires the component to be compiled with `hydratable: true`. Hydration of `<head>` elements requires server-side rendering code also compiled with `hydratable: true`. The `hydrate: true` option causes children of target to be removed, so the `anchor` option cannot be used with it. Existing DOM does not need to exactly match the component as Svelte will repair the DOM during hydration.
$set method in Svelte 3/4
`component.$set(props)` programmatically sets props on a component instance. `component.$set({ x: 1 })` is equivalent to `x = 1` in the component's script block. The method schedules an update for the next microtask; the DOM is not updated synchronously. In Svelte 5+, use `$state` instead to create reactive props.
$on method in Svelte 3/4
`component.$on(ev, callback)` causes the callback function to be called whenever the component dispatches an event. The method returns a function that removes the event listener when called. In Svelte 5+, use callback props instead.
$destroy method in Svelte 3/4
`component.$destroy()` removes a component from the DOM and triggers any `onDestroy` handlers. In Svelte 5+, use `unmount` instead.
Svelte 3/4 server-side component API
Server-side components expose a `render` method callable with optional props. The method returns an object with `head`, `html`, and `css` properties. The `head` property contains contents of `<svelte:head>` elements. Import using `svelte/register` in Node.js to call `Component.render()`.
Svelte 3/4 render method parameters
The `.render()` method accepts `props` ({} by default, object of properties) and `options` ({} by default, object of options). The options object accepts `context` (new Map() by default, root-level context key-value pairs).
$: destructuring assignment in reactive statements
The left-hand side of a reactive assignment can be an identifier or a destructuring assignment, for example: $: ({ larry, moe, curly } = stooges)
$: reactive statements legacy mode overview
In legacy mode, any top-level statement not inside a block or function can be made reactive by prefixing it with a $: label. These statements run after other code in the script and before the component markup is rendered, then whenever the values they depend on change. In runes mode, reactions to state updates are handled with the $derived and $effect runes instead.
$: reactive assignment example
A reactive assignment like '$: sum = a + b' will recalculate sum whenever a or b change. The sum variable does not need to be declared separately.
$: topological ordering of statements
Statements are ordered topologically by their dependencies and assignments. If a console.log statement depends on sum, sum is calculated first even though it appears later in the source code.
$: multiple statements in a block
Multiple reactive statements can be combined by putting them in a block, for example: $: { total = 0; for (const item of items) { total += item.value; } }
$: dependency detection at compile time
The dependencies of a $: statement are determined at compile time. They are whichever variables are referenced (but not assigned to) inside the statement. The compiler cannot detect indirect dependencies.
$: indirect dependency pitfall
A statement like '$: doubled = double()' will not re-run when count changes because the compiler cannot see that double() depends on count. Indirect dependencies are not detected by the compiler.
$: topological ordering with indirect dependencies pitfall
If dependencies are referenced indirectly, topological ordering will fail. For example, if '$: z = y' appears before '$: setY(x)', then z will never update because y is not considered dirty when setY modifies it. Moving '$: z = y' below '$: setY(x)' will fix it.
$: server-side rendering behavior
Reactive statements run during server-side rendering as well as in the browser. Any code that should only run in the browser must be wrapped in an 'if (browser)' block.
Legacy export let syntax for component props
In legacy mode, component props are declared using the export keyword with optional default values. The syntax is 'export let propName' or 'export let propName = defaultValue'. Props without default values are considered required, and Svelte prints a development warning if no value is provided. This pattern was replaced by the $props rune in runes mode.
Legacy prop default values behavior in undefined case
In legacy mode, if a parent component changes a prop from a defined value to undefined, the prop does not revert to its initial default value. This differs from runes mode behavior.
Suppressing required prop warnings in legacy mode
In legacy mode, to suppress the development warning for required props without default values, specify undefined as the default value using 'export let propName = undefined'.
Exported const, class, and function declarations in legacy components
In legacy mode, exporting const, class, or function declarations from a component does not create props. Instead, these become part of the component's public API and can be accessed via bind:this reference to the component instance.
Renaming props in legacy mode with separate export keyword
In legacy mode, the export keyword can appear separately from a variable declaration for renaming purposes. The syntax is 'export { variableName as newName }'. This is useful for creating props with reserved word names, such as 'export { className as class }'.