Forem: Ali Aslam

Mastering Svelte Lifecycle Hooks & Accessibility: Essential Tips for Building Dynamic, Accessible Apps

Ali Aslam — Sat, 13 Sep 2025 05:34:19 +0000

Alright, so we’ve already built some pretty cool stuff—powerful stores, actions, and flexible components that talk to each other. But we’re not done yet! Two things are still missing from our toolbox:

Lifecycle hooks — controlling when your code runs, and cleaning up when components disappear.

Accessibility (a11y) — ensuring your components aren’t just shiny, but also usable for all users.

This article covers both: minimal, powerful lifecycle hooks and practical accessibility patterns you can use immediately.

Part A — Lifecycle Hooks ⏱️

If you’ve used other frameworks:

In React you’d reach for useEffect.
In Vue there are hooks like mounted and beforeUnmount.

In Svelte, lifecycle hooks are minimal but powerful — just what you need, no boilerplate.

`onMount`

Runs after the component first renders in the DOM.

Think of it like Svelte saying:

“Okay, your component is finally on the page — now’s your chance to measure things, fetch data, or wire up events.”

Great for:

Fetching data
Measuring DOM nodes
Adding event listeners

<!-- src/routes/+page.svelte -->
<script>
  import { onMount } from 'svelte';
  let width;

  onMount(() => {
    width = window.innerWidth;

    const handleResize = () => (width = window.innerWidth);
    window.addEventListener('resize', handleResize);

    // cleanup when unmounting
    return () => window.removeEventListener('resize', handleResize);
  });
</script>

<p>Window width: {width}</p>

✅ Without cleanup, you’d leave behind stray resize listeners every time this component mounted/unmounted — a slow memory leak.

`$effect.pre` (before DOM update)

Runs just before Svelte updates the DOM when reactive state changes.

It’s like Svelte tapping you on the shoulder:

“Heads up, I’m about to change the DOM — want to look at the old value first?”

<!-- src/routes/+page.svelte -->
<script>
  let count = 0;

  $effect.pre(() => {
    console.log("Before update: count =", count);
  });

  $effect(() => {
    console.log("After update: count =", count);
  });
</script>

<button onclick={() => count++}>+1</button>

✅ Use $effect.pre when you wanna sneak a peek at the old value before Svelte changes everything. Think of it like getting a look at the ‘before’ picture in a makeover, right before the big transformation!.
❌ Don’t try to edit the DOM here — Svelte will overwrite your changes immediately.

`$effect` (after DOM update)

Runs right after the DOM has been updated.

This is your place to interact with the final DOM: measuring, scrolling, or syncing with third-party libraries.

<!-- src/routes/+page.svelte -->
<script>
  let messages = [];

  function addMessage() {
    messages = [...messages, `Message ${messages.length + 1}`];
  }

  $effect(() => {
    const list = document.querySelector('#messages');
    if (list) list.scrollTop = list.scrollHeight;
  });
</script>

<ul id="messages" style="height:100px; overflow-y:auto;">
  {#each messages as msg}
    <li>{msg}</li>
  {/each}
</ul>

<button onclick={addMessage}>Add message</button>

✅ Perfect for chat apps: each new message scrolls into view automatically.
Think of $effect as your “after the dust settles” hook.

`onDestroy`

Runs when a component is removed from the DOM.

Think of it like cleaning up your campsite before you leave — no timers, no listeners left behind.

<!-- src/routes/+page.svelte -->
<script>
  import { onDestroy } from 'svelte';

  let timer = setInterval(() => console.log('tick'), 1000);

  onDestroy(() => {
    clearInterval(timer);
  });
</script>

<p>Watch the console. When I unmount, timer stops.</p>

✅ Forgetting cleanup here is like leaving your laundry out and never picking it up—eventually, it piles up and starts to smell! You don’t want those stray listeners or timers causing your app to slow down or crash.

Mini Recap 📝

Lifecycle hooks give you a clean way to manage setup, updates, and teardown:

onMount → run setup logic once the DOM is ready
$effect.pre → peek at values before DOM changes
$effect → react after DOM changes
onDestroy → cleanup when leaving

They’re simple, predictable, and cover most real-world needs without extra libraries.

Part B — Accessibility (a11y) ♿

Accessibility isn’t a “nice to have”, it’s a must-have! If your app looks sleek but can’t be used with a keyboard, a screen reader, or by someone with low vision, then for those users…it’s broken.

The good news: Svelte already helps by warning about some a11y issues in the compiler. The rest is up to us — adding semantics, handling focus, and making sure our colors and interactions are usable by everyone.

ARIA Roles 🎭

ARIA roles are like name tags at a party. Without them, assistive tech sees a <div> and goes, “uhh… what are you?”

Example: modal dialog.

<!-- src/routes/+page.svelte -->
<div role="dialog" aria-labelledby="title" aria-modal="true">
  <h2 id="title">Confirm Delete</h2>
  <button>Cancel</button>
  <button>Delete</button>
</div>

✅ Now screen readers know: “This is a dialog with a title.” Not just a random <div>.

Keyboard Navigation ⌨️

Everything should work without a mouse. Menus, tabs, dialogs — they all need keyboard support.

<!-- src/routes/+page.svelte -->
<script>
  let items = ['Home', 'About', 'Contact'];
  let current = 0;

  function handleKey(e) {
    if (e.key === 'ArrowDown') current = (current + 1) % items.length;
    if (e.key === 'ArrowUp') current = (current - 1 + items.length) % items.length;
  }
</script>

<ul tabindex="0" onkeydown={handleKey}>
  {#each items as item, i}
    <li class:active={i === current}>{item}</li>
  {/each}
</ul>

<style>
  li.active {
    background: #ddd;
  }
</style>

✅ Try the arrow keys — focus moves up and down the list like you’d expect.

Focus Management 🎯

When a modal opens, focus should jump into it. Otherwise, keyboard users can get stuck “behind the curtain.”

<!-- src/routes/+page.svelte -->
<script>
  import { onMount } from 'svelte';
  let modal;

  onMount(() => {
    modal.querySelector('button').focus();
  });
</script>

<div role="dialog" bind:this={modal}>
  <h2>Welcome</h2>
  <button>Close</button>
</div>

✅ Now, the focus jumps straight to the button like a spotlight on stage! No more awkwardly tabbing through the background—your keyboard users will love you for this.

Labels & Inputs 🏷️

Inputs need proper labels — otherwise screen readers just announce “edit text” with no context.

<!-- Using "for" / "id" -->
<label for="email">Email</label>
<input id="email" type="email" />

Or the wrapping style:

<label>
  Email
  <input type="email" />
</label>

✅ Both are fully screen-reader friendly.

Color Contrast 🎨

Designers love light grays, but your eyes (and your users’) don’t.

Use the WebAIM contrast checker to make sure text is readable.

✅ Aim for at least 4.5:1 contrast ratio for normal text.

Live Regions 🔊

When something changes in your app (like a new message or notification), you want to make sure your users know about it, right? That’s where aria-live comes in. It’s like having an invisible helper announcing changes, so no one misses out!

<!-- src/routes/+page.svelte -->
<script>
  let message = "Ready.";
</script>

<p aria-live="polite">{message}</p>
<button onclick={() => message = "Saved!"}>Save</button>

✅ When you click “Save,” screen readers will literally speak the word “Saved!”

Real-World Example: Accessible Tabs 🗂️

Let’s build a set of tabs that play nicely with both keyboards and screen readers.

<!-- src/lib/components/Tabs.svelte -->
<script>
  export let tabs = [];
  export let children;
  let active = 0;
</script>

<div role="tablist">
  {#each tabs as tab, i}
    <button
      role="tab"
      aria-selected={i === active}
      aria-controls={"panel-" + i}
      id={"tab-" + i}
      onclick={() => (active = i)}
    >
      {tab.label}
    </button>
  {/each}
</div>

{#each tabs as tab, i}
  <div
    id={"panel-" + i}
    role="tabpanel"
    aria-labelledby={"tab-" + i}
    hidden={i !== active}
  >
    {@render children?.({ name: tab.name })}
  </div>
{/each}

Usage

<!-- src/routes/+page.svelte -->
<script>
  import Tabs from '$lib/components/Tabs.svelte';

  let tabs = [
    { label: 'One', name: 'one' },
    { label: 'Two', name: 'two' }
  ];
</script>

<Tabs {tabs}>
  {({ name }) => {
    if (name === 'one') return <div>Tab one content</div>;
    if (name === 'two') return <div>Tab two content</div>;
  }}
</Tabs>

✅ Tabs announce which one is active, link each button to its panel, and properly hide inactive panels.

👉 Accessibility is less about “extra features” and more about “basic usability for everyone.” With a few small habits — roles, labels, focus, contrast — your app becomes usable by all your users, not just some.

Accessible Modal (Mini Project) 🪟♿

Let’s put everything together and build an accessible modal component.

It should:

Announce itself properly with role="dialog" + aria-modal="true".
Automatically move focus inside when opened.
Trap focus so tabbing doesn’t “escape” to the background.
Close when you hit Escape.

Think of it like a pop-up window in real life:

The curtain drops (backdrop),
The spotlight shines inside (focus),
And you can’t wander off until you close it.

Modal Component

<!-- src/lib/components/Modal.svelte -->
<script>
  import { onMount } from 'svelte';
  export let open = false;
  let modal;

  function close() {
    open = false;
  }

  function handleKey(e) {
    if (e.key === 'Escape') close();

    // Basic focus trap
    if (e.key === 'Tab' && modal) {
      const focusable = modal.querySelectorAll(
        'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'
      );
      const first = focusable[0];
      const last = focusable[focusable.length - 1];

      if (e.shiftKey && document.activeElement === first) {
        e.preventDefault();
        last.focus();
      } else if (!e.shiftKey && document.activeElement === last) {
        e.preventDefault();
        first.focus();
      }
    }
  }

  onMount(() => {
    if (open) {
      modal.querySelector('button')?.focus();
      document.addEventListener('keydown', handleKey);
    }

    return () => {
      document.removeEventListener('keydown', handleKey);
    };
  });
</script>

{#if open}
  <div class="backdrop">
    <div
      role="dialog"
      aria-modal="true"
      aria-labelledby="modal-title"
      bind:this={modal}
    >
      <h2 id="modal-title">Confirm Action</h2>
      <button onclick={close}>Cancel</button>
      <button onclick={close}>Confirm</button>
    </div>
  </div>
{/if}

<style>
  .backdrop {
    position: fixed;
    inset: 0;
    background: rgba(0, 0, 0, 0.5);
    display: flex;
    justify-content: center;
    align-items: center;
  }

  [role="dialog"] {
    background: white;
    padding: 2rem;
    border-radius: 8px;
    min-width: 300px;
  }

  button {
    margin: 0.5rem;
  }
</style>

Using the Modal

<!-- src/routes/+page.svelte -->
<script>
  import Modal from '$lib/components/Modal.svelte';
  let show = false;
</script>

<button onclick={() => (show = true)}>Open Modal</button>

<Modal bind:open={show} />

Why this is accessible

✅ Semantic roles: role="dialog" + aria-modal="true" tell assistive tech this is a modal, not just another <div>.

✅ Focus management: When the modal opens, focus jumps straight to the first button. Users don’t get lost in the background.

✅ Focus trap: Pressing Tab cycles between buttons inside the modal — you can’t tab into the page behind it.

✅ Escape key: Hitting Escape closes the modal, no mouse required.

This little modal combines:

Lifecycle hooks (onMount) for setup and cleanup,
Keyboard handling for Escape/Tab,
Accessibility best practices for roles, focus, and labels.

It’s a real-world component that feels good to use whether you’re on a mouse, keyboard, or screen reader.

With these patterns, you’re officially building like a pro.

👉 Next in the series: Performance & Scaling — optimizing reactivity, code splitting, lazy loading, and testing.

Follow me on DEV for future posts in this deep-dive series.
https://dev.to/a1guy
If it helped, leave a reaction (heart / bookmark) — it keeps me motivated to create more content
Checkout my offering on YouTube with (growing) crash courses and content on JavaScript, React, TypeScript, Rust, WebAssembly, AI Prompt Engineering and more: @LearnAwesome

Mastering DOM Manipulation with Svelte Actions and Children

Ali Aslam — Sat, 13 Sep 2025 05:08:04 +0000

In Svelte, Actions and Children are powerful tools that make your components more dynamic and reusable. Whether you're adding behaviors like focus management, handling resizing, or giving parents the ability to inject custom content, these features are essential for building interactive and flexible UIs.

This guide will show you how to leverage Actions to add reusable DOM behaviors and Children to make your components more adaptable. By the end, you'll be able to create components that feel like LEGO blocks—small, composable, and easy to work with.

Why Actions? 🎬

We’ve seen how stores help with state management.
But what about reusing behavior on DOM elements?

While state management (via stores) helps us manage data, actions focus on controlling the behavior of DOM elements. They let us add reusable behaviors, like autofocus, clicks, resizing, and much more, making our components more flexible and powerful.

Stores vs Actions

Stores → centralize and share state
Actions → centralize and reuse DOM behavior

The problem

Imagine you want multiple inputs to autofocus when they appear.
Without actions, you’d write the same onMount logic in every component:

<script>
  import { onMount } from 'svelte';
  let input;
  onMount(() => input.focus());
</script>

<input bind:this={input}>

It works, but it’s copy-pasted boilerplate. 😩

The idea

With an action, you write the focus logic once and then attach it to any element using the use: directive.

Think of actions as hooks for DOM nodes — little reusable plugins you can stick on elements.

Your First Action: Autofocus 👀

Let’s turn that autofocus behavior into an action.

Action file

// src/lib/actions/focus.js
export function autofocus(node) {
  node.focus();
}

Usage in a page

<!-- src/routes/+page.svelte -->
<script>
  import { autofocus } from '$lib/actions/focus.js';
</script>

<input placeholder="Type here..." use:autofocus />

How it works

When the <input> mounts, Svelte calls our autofocus function with the DOM node.
The action immediately runs node.focus().
Result: the input gets focus automatically, no onMount needed in your component.

✅ You can now sprinkle use:autofocus anywhere without repeating logic. The use: directive is the key to applying actions to DOM elements. It tells Svelte to run the action on the DOM element when it mounts, providing a simple and reusable way to handle behaviors.

Actions with Cleanup 🧹

Some DOM behaviors need to attach event listeners (like click, keydown, or scroll).
But here’s the catch: if you don’t remove those listeners when the element goes away, you’ll create memory leaks.

Actions solve this neatly because they can return an object with special lifecycle methods:

destroy() → runs when the element is removed from the DOM
update(params) → runs if the parameter to the action changes (we’ll cover this in the next step)

Example: Click Outside Detector

Let’s make an action that closes a modal or dropdown when you click outside of it.

// src/lib/actions/clickOutside.js
export function clickOutside(node, callback) {
  function handle(event) {
    if (!node.contains(event.target)) {
      callback();
    }
  }

  document.addEventListener('click', handle, true);

  return {
    destroy() {
      document.removeEventListener('click', handle, true);
    }
  };
}

Usage in a component

<!-- src/routes/+page.svelte -->
<script>
  import { clickOutside } from '$lib/actions/clickOutside.js';
  let open = true;
</script>

{#if open}
  <div use:clickOutside={() => (open = false)}>
    Click outside me to close.
  </div>
{/if}

Why this works

When the <div> mounts, the action attaches a click listener on document.
If you click anywhere outside the <div>, the callback runs and sets open = false.
When the <div> is removed, the destroy() method is called, which cleans up the event listener. This cleanup is essential because, without it, event listeners would continue to exist even after the element is removed from the DOM, leading to unnecessary memory consumption and potential performance issues

✅ This is perfect for modals, dropdowns, sidebars, or tooltips that should close when you click elsewhere.

⚠️ Without the destroy() cleanup, every new modal would add another document.addEventListener — piling up over time, slowing down your app, and causing weird bugs.

Actions with Parameters 🎛️

Actions don’t just run once — they can also react to changing arguments.

When you write use:myAction={value}, Svelte does three things under the hood:

Calls the action when the element mounts → myAction(node, value)
Calls update(newValue) whenever the parameter changes
Calls destroy() when the element is removed

This makes actions really flexible — they can adapt as your component’s state changes. By passing parameters to actions, we can make them highly dynamic and reusable. For example, resizing a box based on a slider or updating styles based on a value changes without needing to repeat logic in each component.

Example: Resize Box

Here’s an action that resizes a box based on a numeric parameter.

// src/lib/actions/resize.js
export function resize(node, size) {
  function apply(size) {
    node.style.width = size + 'px';
    node.style.height = size + 'px';
  }

  // run once on mount
  apply(size);

  return {
    update(newSize) {
      apply(newSize); // run whenever `size` changes
    },
    destroy() {
      // cleanup: reset styles
      node.style.width = '';
      node.style.height = '';
    }
  };
}

Usage in a page

<!-- src/routes/+page.svelte -->
<script>
  import { resize } from '$lib/actions/resize.js';
  let boxSize = 100;
</script>

<div use:resize={boxSize} style="background: coral;"></div>

<input type="range" min="50" max="300" bind:value={boxSize} />

How it works

On mount, the action sets the <div>’s width and height to boxSize (100px to start).
As you move the slider, boxSize changes → Svelte calls the action’s update() → the box resizes in real time.
When the <div> is removed, destroy() resets its styles.

✅ The result: a resizable box that updates instantly as the slider moves.

Advanced Actions (Extra Examples) 🚀

By now you’ve seen how actions can add reusable behavior to DOM elements.
Let’s bring back some extra goodies from the old draft — actions that are a bit more advanced but super useful in real apps.

1. Debounced Input ⏳

Throttle keystrokes before firing off expensive work (like API requests).

// src/lib/actions/debounce.js
export function debounce(node, delay = 300) {
  let timeout;

  function handler(e) {
    clearTimeout(timeout);
    timeout = setTimeout(() => {
      node.dispatchEvent(
        new CustomEvent('debounced', { detail: e.target.value })
      );
    }, delay);
  }

  node.addEventListener('input', handler);

  return {
    destroy() {
      node.removeEventListener('input', handler);
    }
  };
}

Usage

<!-- src/routes/+page.svelte -->
<script>
  import { debounce } from '$lib/actions/debounce.js';
  let search = '';
</script>

<input
  use:debounce={500}
  on:debounced={(e) => (search = e.detail)}
  placeholder="Search..."
/>

<p>Search query: {search}</p>

✅ Super handy for search boxes — you don’t want to hammer your backend on every single keystroke. Debouncing helps optimize user experience by reducing unnecessary API calls, especially when dealing with search inputs, live validation, or any component that reacts to user typing.

2. Drag and Drop (Basic) 🖱️

Make elements draggable with almost no code.

// src/lib/actions/draggable.js
export function draggable(node) {
  node.draggable = true;

  function handleDragStart(e) {
    e.dataTransfer.setData('text/plain', node.id);
    node.classList.add('dragging');
  }

  function handleDragEnd() {
    node.classList.remove('dragging');
  }

  node.addEventListener('dragstart', handleDragStart);
  node.addEventListener('dragend', handleDragEnd);

  return {
    destroy() {
      node.removeEventListener('dragstart', handleDragStart);
      node.removeEventListener('dragend', handleDragEnd);
    }
  };
}

Usage

<!-- src/routes/+page.svelte -->
<script>
  import { draggable } from '$lib/actions/draggable.js';
</script>

<div id="card1" use:draggable class="card">Drag me!</div>

<style>
  .card {
    padding: 1rem;
    background: coral;
    width: 120px;
    border-radius: 8px;
    cursor: grab;
  }

  .dragging {
    opacity: 0.5;
  }
</style>

✅ Perfect for building kanban boards, sortable lists, or any drag-n-drop UI.

Mini Recap 📝

So far you’ve learned:

Actions attach reusable DOM behavior with the use: directive.
They can:
- clean up (destroy)
- react to parameter changes (update)
- even dispatch custom events back to your components.

Together we built:

autofocus (simple mount logic)
clickOutside (cleanup on destroy)
resize (parameters & updates)
debounce (custom events)
draggable (real DOM APIs)

Extra Notes for Beginners

🔹 Debounce:
When we call node.dispatchEvent(new CustomEvent(...)), we’re basically saying:
“Pretend this is a normal DOM event.”
That’s why in your component you can listen with onDebounced just like onClick.

🔹 Draggable:
node.draggable = true; is just enabling the browser’s built-in drag support.
We’re not moving elements around yet — just marking them as draggable and styling them while they’re being dragged. That’s why this version is “basic.” You could extend it later with drop zones or reordering logic.

✨ And that’s actions! Small functions that give your elements reusable superpowers.

Next: let’s explore children, Svelte’s secret weapon for flexible component composition.

Why Children? 👶

Props let parents send data to children.
Children let parents send content to children.

They’re the backbone of reusable UI libraries — think buttons, cards, layouts, modals. While actions manipulate the behavior of DOM elements (like adding click event listeners or resizing an element), children allow parents to inject content into components. Together, actions and children make your components more dynamic and reusable

👉 Children are like cutouts in your component where parents can inject their own content.

Default Children 📦

Sometimes you don’t just want your component to look nice — you want it to be a container for other stuff. That’s what the children prop is for.

It’s like saying:
“Hey parent, you tell me what goes inside, and I’ll handle the wrapper.”

Example: Card Component

<!-- src/lib/components/Card.svelte -->
<script>
  export let children;
</script>

<div class="card">
  {@render children?.()}
</div>

<style>
  .card {
    border: 1px solid #ddd;
    border-radius: 6px;
    padding: 1rem;
  }
</style>

Using the Card

<!-- src/routes/+page.svelte -->
<script>
  import Card from '$lib/components/Card.svelte';
</script>

<Card>
  <h2>Hello</h2>
  <p>This is inside the card!</p>
</Card>

✨ Boom! Whatever you write between <Card> ... </Card> gets passed into the children prop and rendered inside.

Think of it like a bento box 🍱: the Card provides the container, you provide the delicious filling.

Named Children 🧁

What if your component has multiple areas — like header, body, and footer — instead of just one?

You can accept named children, which are just props that are functions returning content.

Example: Layout Component

<!-- src/lib/components/Layout.svelte -->
<script>
  export let header;
  export let footer;
  export let children; // default area
</script>

<header>{@render header?.()}</header>
<main>{@render children?.()}</main>
<footer>{@render footer?.()}</footer>

Using the Layout

<!-- src/routes/+page.svelte -->
<script>
  import Layout from '$lib/components/Layout.svelte';
</script>

<Layout
  header={() => <h1>My Site</h1>}
  footer={() => <small>© 2025</small>}
>
  <p>Main content goes here.</p>
</Layout>

✅ Each piece gets dropped exactly where you want it.

Think of it like a muffin tray 🧁: each “cup” has its own filling.

Fallback Children 📝

Sometimes parents don’t pass anything in. Should your component be an empty shell? Nope! You can provide default content instead.

Example: Button Component

<!-- src/lib/components/Button.svelte -->
<script>
  export let children = () => "Click me";
</script>

<button>{@render children()}</button>

Using the Button

<!-- src/routes/+page.svelte -->
<script>
  import Button from '$lib/components/Button.svelte';
</script>

<Button />            <!-- shows "Click me" -->
<Button>Save</Button> <!-- shows "Save" -->

✅ If the parent passes children, those take priority. Otherwise, the component politely falls back to its default.

It’s like leaving a friendly sticky note:

“Forgot to pass me something? No worries, I got you 👍”

Children as Render Functions (Child → Parent) 🔄

Here’s the really cool part: children don’t have to just be static content — they can be functions that receive data from the child component.

That means:

The child decides when to render something (like looping through a list).
The parent decides how it should look.

Example: List Component

<!-- src/lib/components/List.svelte -->
<script>
  export let items = [];
  export let children;
</script>

<ul>
  {#each items as item}
    <li>{@render children({ item })}</li>
  {/each}
</ul>

Using the List

<!-- src/routes/+page.svelte -->
<script>
  import List from '$lib/components/List.svelte';
</script>

<List items={['Ada', 'Grace', 'Linus']}>
  {({ item }) => <span>{item.toUpperCase()}</span>}
</List>

✅ The List component controls when to render each <li>.
✅ The parent controls what each item looks like — in this case, uppercased names.

It’s like the child saying: “Here’s the data,” and the parent replying: “Cool, I’ll dress it up.” 🎨

Gotchas & Best Practices ⚠️

Always provide fallback children so your component doesn’t break if nothing is passed in.
When looping with {#each}, always use keys (e.g. {#each items as item (item.id)}) to avoid weird DOM recycling bugs.
Children-as-functions are powerful, but keep it simple — only pass the data the parent actually needs.

We covered a lot of ground here:

Actions: from a one-liner autofocus to advanced behaviors with cleanup, parameters, and custom events.

Children: from default content, to named sections, to render functions that let parents customize rendering logic.

These patterns make your components smarter and more reusable.
👉 Next, we’ll tie things together with Svelte Lifecycle Hooks and Accessibility — ensuring your components behave correctly over time and are usable by everyone.

Mastering Svelte Custom Stores

Ali Aslam — Sat, 13 Sep 2025 04:39:25 +0000

By now you’ve seen props, context, stores, and even forms with actions. Those give you 80% of what you need to build solid Svelte apps. But at some point you’ll hit cases where the simple writable or derived store isn’t quite enough.

That’s where custom stores come in.

Think of them as stores with superpowers: instead of just holding state, they can also embed business logic, persistence, or side effects.

We’ll build from scratch: a counter, a persistent theme toggle, and a more complex store that handles authentication. Along the way we’ll highlight where to place the files in your project structure and the subtle gotchas (like SSR vs browser code).

Step 1 — Quick recap: basic stores 🧰

In Svelte, a store is a small object that represents shared, subscribable state. Concretely, a store is anything that implements the store contract — i.e. it exposes a .subscribe() method that consumers can subscribe to.

Stores are great when multiple components need to read or update the same value (think: theme, auth user, counters shared across pages). Svelte also gives you a very convenient shorthand inside .svelte components: prefix a store name with $ to auto-subscribe and read its current value reactively. That $ shortcut only works inside Svelte component files.

Create the simplest store (a counter)

Save this in src/lib/stores/basic.js:

// src/lib/stores/basic.js
import { writable } from 'svelte/store';

// create a writable store with an initial value of 0
export const count = writable(0);

writable(0) creates a store you can read from and write to. The returned object has .subscribe(), .set(), and .update() methods.

Use the store in a page/component

<!-- src/routes/+page.svelte -->
<script>
  import { count } from '$lib/stores/basic.js';
</script>

<p>Count: {$count}</p>
<button onclick={() => $count += 1}>+1</button>

Notes on that example:

{$count} — the $ shorthand auto-subscribes to count and inserts the current value into the template. When the store changes, the DOM updates automatically.
onclick={() => $count += 1} — inside a component you may assign to $count directly; that updates the underlying store. (Equivalent alternatives are shown below.)

Alternative ways to update the store

You can pick whichever style reads best to you — they all update the store:

<!-- using set -->
<button onclick={() => count.set($count + 1)}>+1 (set)</button>

<!-- using update -->
<button onclick={() => count.update(n => n + 1)}>+1 (update)</button>

.set(value) replaces the store value.
.update(updater) receives the current value and returns the next value. Both are the canonical store APIs from the svelte/store module.

Important caveats & beginner tips

The $ shortcut only works inside .svelte components. If you need a store’s value inside plain .js/.ts files, use .subscribe() or get(store) helper patterns instead.
Stores are ideal for shared state. For purely local component state, you can use plain reactive variables — but when multiple components need the same data, stores are the right tool.
When you export a store from a module (like src/lib/stores/basic.js), you’re exporting a single shared instance — every import gets the same store object. That’s why stores are handy for application-wide values (theme flags, user object, simple caches).

💡 Why this matters (short and sweet):
Stores give you a tiny, predictable API (subscribe, set, update) to share and react to values across components. The $ shortcut makes consuming them effortless in templates — write less plumbing, focus on the logic.

Step 2 — Why Custom Stores? 🤔

Our simple counter works — but what happens when requirements change?

For example:

Only allow the count to go up to a maximum (say 10).
Keep track of how many times users pressed the button.
Reset automatically after 5 minutes.

If every component has its own button logic, you’d have to copy-paste those rules everywhere. That quickly leads to bugs when one place forgets a rule.

👉 This is where custom stores come in.

Think of it like this:

A basic store is just a box with a number inside.
A custom store is a box with a remote control: you can press “increment,” “reset,” or “decrement” without touching the number directly.

This way:

All your rules (max value, history, reset timer) live inside the store.
Components only call the safe methods you expose — not the raw set/update.

That makes your app more consistent and less error-prone.

Step 3 — The simplest custom store 🛠️

So far, our counter store was just a box with a number. Components reached in directly and did things like count.set(...) to change it. That works, but it means each component needs to know the exact rules for updating the store.

With a custom store, we move the logic inside the store instead of scattering it across components. Components don’t touch the raw number anymore — they just call simple, safe methods.

The recipe for a custom store

Start with a writable store (as before).
Wrap it in a function that returns an object.
That object must include:

.subscribe (so you can still use the $counter shorthand in components)
Any extra methods you want, like increment, decrement, or reset.

Think of it as building a “remote control” 📺 for your store. Instead of every component fiddling with the wires, they just press a button on the remote.

Store file

// src/lib/stores/counterStore.js
import { writable } from 'svelte/store';

function createCounter() {
  // start with 0
  const { subscribe, set, update } = writable(0);

  return {
    // expose subscribe so $counter works in components
    subscribe,

    // custom methods instead of exposing set/update directly
    increment: () => update(n => n + 1),
    decrement: () => update(n => n - 1),
    reset: () => set(0)
  };
}

// export ONE instance of this store
export const counter = createCounter();

Component using the store

<!-- src/routes/+page.svelte -->
<script>
  import { counter } from '$lib/stores/counterStore.js';
</script>

<h2>Counter: {$counter}</h2>

<button onclick={counter.increment}>+</button>
<button onclick={counter.decrement}>-</button>
<button onclick={counter.reset}>Reset</button>

✅ Now notice

Components don’t know about set or update anymore.
They just call the public methods (increment, decrement, reset), like pressing buttons on a remote control.
All the rules live in one place → reusable, consistent, and easy to test.

💡 A helpful analogy

If you’ve ever used Redux (or another state manager), custom stores might feel familiar. Like Redux, they centralize state + logic so components don’t manage everything themselves.

But here’s the best part:

No reducers.
No action types.
No boilerplate at all.

Just plain JavaScript methods (increment, reset…), and the $counter automatically keeps your UI in sync. ✨

Step 4 — Adding constraints & business rules ⚖️

Right now our counter can go up and down with no limits. That’s fun for a demo, but real apps usually come with rules. For example:

Don’t let the counter go above a maximum.
Don’t let it go below zero.
Keep a history of changes so we can debug or display them later.

Instead of sprinkling those checks across every component, let’s put them inside the store. That way, all components automatically follow the same rules.

Store with constraints + history

// src/lib/stores/counterStore.js
import { writable } from 'svelte/store';

function createCounter(max = 10) {
  const { subscribe, set, update } = writable(0);

  // local variable (not exported) to track history
  let history = [];

  return {
    subscribe,

    increment: () => update(n => {
      // never go above max
      const next = Math.min(max, n + 1);
      history.push(next); // record the new value
      return next;
    }),

    decrement: () => update(n => {
      // never go below zero
      const next = Math.max(0, n - 1);
      history.push(next);
      return next;
    }),

    reset: () => {
      history.push(0);
      set(0);
    },

    // public method to read the history
    getHistory: () => history
  };
}

// here we create a counter that stops at 5
export const counter = createCounter(5);

Using the store in a page

<!-- src/routes/+page.svelte -->
<script>
  import { counter } from '$lib/stores/counterStore.js';

  // local history variable
  let history = [];

  function refreshHistory() {
    history = counter.getHistory();
  }
</script>

<h2>Counter: {$counter}</h2>

<button onclick={() => { counter.increment(); refreshHistory(); }}>+</button>
<button onclick={() => { counter.decrement(); refreshHistory(); }}>-</button>
<button onclick={() => { counter.reset(); refreshHistory(); }}>Reset</button>

<h3>History</h3>
<ul>
  {#each history as h}
    <li>{h}</li>
  {/each}
</ul>

What’s happening here?

Constraints:
- Math.min(max, n + 1) ensures the value never goes above the maximum.
- Math.max(0, n - 1) ensures the value never goes below zero.
History:
Every time the counter changes, we push the new value into the history array.
Encapsulation:
The history array lives inside the store. Components can’t mess with it directly — they can only access it through getHistory().

✅ Benefits

Components stay simple. They just call counter.increment() and don’t need to worry about limits.
All the business rules are in one place. If requirements change, you update the store, not every button.

Beginner note

$counter is reactive — it updates the <h2> automatically when the store changes.
counter.getHistory() is just a plain function. It doesn’t auto-update, which is why we call it after each button press to refresh the history variable.
If you wanted history itself to be reactive, you’d make it its own store — that’s a more advanced pattern we’ll cover later.

Step 5 — Persistent stores with `localStorage` 💾

Sometimes you’ll want data to stick around even after a page refresh — things like:

Dark/light theme
Remembering filters
“Stay logged in” preference

That’s where the browser’s localStorage comes in.

The SvelteKit Catch 🤯

SvelteKit apps run in two places:

On the server (when it first renders a page)
On the browser (after hydration)

The server doesn’t have localStorage — it only exists in the browser. If you try to use it directly, your app will crash during server-side rendering (SSR).

So, before we touch it, we need to check if we’re running in the browser.

Store with Persistence

Now, let’s take a look at how we can create a store that persists data in localStorage. But remember, when running on the server, localStorage isn't available, so we need to make sure we only access it in the browser.

Here’s how you can create a theme store that remembers the user’s preferred theme between page reloads:

// src/lib/stores/themeStore.js
import { writable } from 'svelte/store';
import { browser } from '$app/environment'; // Import the 'browser' utility from SvelteKit

function createTheme() {
  // Get initial value safely
  const initial = browser
    ? localStorage.getItem('theme') || 'light' // Check if we're in the browser before accessing localStorage
    : 'light'; // Default to 'light' theme if not in the browser

  const { subscribe, set, update } = writable(initial);

  return {
    subscribe,
    toggle: () =>
      update(t => {
        const next = t === 'light' ? 'dark' : 'light'; // Toggle theme between light and dark
        if (browser) { // Only set item in localStorage if we're in the browser
          localStorage.setItem('theme', next);
        }
        return next;
      }),
    set
  };
}

export const theme = createTheme();

Usage in a Page

Next, we use the store in a page to switch between light and dark themes. Here's how you can bind the theme to the body element so that it updates the page styling accordingly.

<!-- src/routes/+page.svelte -->
<script>
  import { theme } from '$lib/stores/themeStore.js';

  // Keep <body> class in sync with the current theme
  $effect(() => {
    document.body.classList.remove('light', 'dark'); // Remove old theme class
    document.body.classList.add($theme); // Add the current theme class
  });
</script>

<button onclick={theme.toggle}>
  Switch to {$theme === 'light' ? 'dark' : 'light'} mode
</button>

<style>
  /* Global selectors so they actually style the real <body> */
  :global(body.light) {
    background: white;
    color: black;
  }

  :global(body.dark) {
    background: #121212;
    color: white;
  }

  button {
    margin-top: 1rem;
    padding: 0.5rem 1rem;
    border-radius: 6px;
  }
</style>

How This Works

✅ Initial value: When the store is created, it checks localStorage for a saved theme. If none is found, it defaults to "light".

✅ Toggling: Clicking the button flips the theme between "light" and "dark", and the new value is saved back to localStorage.

✅ Syncing <body>: The $effect keeps the <body> element’s class in sync with the current theme. Whenever $theme changes, it updates the class list so <body> always reflects the latest value.

✅ Styling with :global(): Svelte normally scopes CSS selectors to a single component. If you wrote body.dark { ... } without :global(), it would compile into something like body.dark.svelte-xyz123, which won’t match the real <body>.

That’s why we wrap it in :global(...):

:global(body.dark) { … }

This tells Svelte “apply this to the actual global <body> element.” Now, when the store updates the class, the CSS takes effect, and you see the whole page background and text color change.

⚠️ Without the browser check, this would crash on the server, because localStorage doesn’t exist during SSR.

✅ End result: The user’s theme preference is saved, restored on refresh, and visibly changes the entire page without hydration issues.

Step 6 — A more advanced custom store: Auth 👤🔑

So far, our stores have just held numbers or strings. Let’s try something more real: an authentication store.

This store should:

Remember who the current user is
Expose login() and logout() methods
Persist the user in localStorage (so a refresh doesn’t log you out)
Restore the user (hydrate) on page load

Auth store

// src/lib/stores/authStore.js
import { writable } from 'svelte/store';

function createAuth() {
  const { subscribe, set } = writable(null); // start with no user

  // Try to restore user from localStorage
  if (typeof localStorage !== 'undefined') {
    const saved = localStorage.getItem('user');
    if (saved) {
      set(JSON.parse(saved)); // parse string back into an object
    }
  }

  return {
    subscribe,

    // fake login for demo purposes
    login: (user) => {
      set(user);
      if (typeof localStorage !== 'undefined') {
        localStorage.setItem('user', JSON.stringify(user));
      }
    },

    // logout clears store + localStorage
    logout: () => {
      set(null);
      if (typeof localStorage !== 'undefined') {
        localStorage.removeItem('user');
      }
    }
  };
}

export const auth = createAuth();

Using the auth store in a page

<!-- src/routes/+page.svelte -->
<script>
  import { auth } from '$lib/stores/authStore.js';
</script>

{#if $auth}
  <p>Welcome, {$auth.name}!</p>
  <button onclick={auth.logout}>Logout</button>
{:else}
  <button onclick={() => auth.login({ name: 'Ada' })}>
    Login as Ada
  </button>
{/if}

What’s happening here?

\$auth value:
- null → no user logged in
- an object → e.g. { name: "Ada" }
login(user): updates the store and saves the user object into localStorage.
logout(): clears the store and removes the user from localStorage.
Automatic hydration: when the store is created, it checks localStorage. If a user was saved from a previous session, it restores them right away.

✅ Why this is powerful

Now our store behaves almost like a mini service inside the app. Components don’t need to know how login works — they just call auth.login() or auth.logout().

Later, if you replace the fake login() with a real API call, none of the consuming components would need to change. Everything is centralized and consistent.

Step 7 — Gotchas & Best Practices ⚠️

Custom stores are powerful, but there are a few common pitfalls you’ll want to avoid. Let’s go through them.

1. Don’t mutate state outside the store 🛑

Bad:

// ❌ direct mutation (don’t do this!)
counter.history.push(123);

Good:

// ✅ only change state via store methods
counter.increment();

➡️ Think of a store as a black box. Components shouldn’t reach inside and poke at its internals. If you need to change something, expose a method on the store and use that.

2. SSR vs Browser 🌍

Remember: in SvelteKit, your code runs both

on the server (during the first render)
in the browser (after hydration)

But things like localStorage, window, and document only exist in the browser.

So always guard them:

if (typeof localStorage !== 'undefined') {
  // safe to use
}

Or, SvelteKit provides a helper:

import { browser } from '$app/environment';

if (browser) {
  // safe to use
}

Without these guards, your app will crash during SSR.

3. Testing is easy 🧪

One of the best things about stores: they’re just plain JavaScript objects with functions. That makes them simple to test, without any Svelte setup at all.

import { counter } from '$lib/stores/counterStore';
import { get } from 'svelte/store';

counter.increment();
expect(get(counter)).toBe(1);

Here we’re using get() from svelte/store to synchronously read the store’s current value.

4. Don’t over-engineer ⚙️

Not every store needs to be custom.

If your state is just a number, string, or boolean → stick with writable().
Reach for a custom store when you need extra rules (like validation, persistence, history, or side effects).

Think of custom stores as the “power tool” 🛠️ — handy when needed, but overkill for a single nail.

✅ Keep these in mind and you’ll avoid the common pitfalls, while knowing exactly when custom stores are worth the effort.

And that’s custom stores in action:
Simple counters → custom logic
Business rules → encapsulated in one place
Persistence with localStorage
Real-world auth example

Stores are the backbone of Svelte apps — once you master them, you’ll find state management much easier and cleaner.

👉 Next up: we’ll look at Mastering DOM Manipulation with Svelte Actions and Children, which let you attach reusable behavior to DOM nodes and build flexible component APIs.

Forms in SvelteKit — Actions, Validation & Progressive Enhancement

Ali Aslam — Wed, 10 Sep 2025 08:08:01 +0000

Let’s be honest: most apps aren’t impressive because of their fancy buttons or slick layouts. What makes them useful is the stuff you can actually do.

Think about it:

A blog without a comment box? That’s just a PDF with nicer fonts.
An online store without a checkout form? Nothing more than a digital catalog.
A dashboard without settings? Basically a poster that updates itself.

👉 Forms are where your users get to talk back to your app.

Here’s the catch: in many frameworks, building forms feels like busywork. You end up juggling fetch() calls, event listeners, and custom validation code. Miss one tiny detail and your whole flow collapses. Worse, if JavaScript fails (or is disabled), the form stops working entirely.

SvelteKit flips this on its head. Instead of saying “let’s rebuild forms in JavaScript,” it says:

Use the HTML forms you already know.
They’re accessible by default.
They keep working without JavaScript.
They handle flaky networks gracefully.

Then, if JavaScript is available, SvelteKit quietly upgrades them with progressive enhancement so they feel as smooth as any SPA form.

That’s the secret sauce: you don’t start fragile and patch on resilience later. You start rock-solid, and only add extra sprinkles when you want them.

In this first part we’ll:

Build a contact form that’s 100% HTML.
Watch how the browser handles submission all on its own.
See how SvelteKit slots into that flow with the special form prop.
Call out some easy mistakes beginners make (and how to dodge them).

Later we’ll tackle validation, error handling, redirects, uploads, and even a mini project. But first, let’s pour the foundation.

Step 1 — Create the contact page

Here’s the simplest possible form you can add to a SvelteKit route.

📂 File: src/routes/contact/+page.svelte

<!-- src/routes/contact/+page.svelte -->
<script>
  // SvelteKit will inject a `form` object after submissions
  let { form } = $props();
</script>

<h1>Contact us</h1>

{#if form?.message}
  <p class="success">✅ {form.message}</p>
{/if}

<form method="POST">
  <label>
    Your name
    <input name="name" required />
  </label>

  <label>
    Your email
    <input type="email" name="email" required />
  </label>

  <label>
    Message
    <textarea name="text" rows="5" required></textarea>
  </label>

  <button type="submit">Send</button>
</form>

<style>
  form { display: grid; gap: 0.6rem; max-width: 40rem; }
  label { display: grid; gap: 0.25rem; }
  .success { color: #0a7; }
</style>

That’s it — a real HTML form, with three fields and a submit button.

Notice the placeholder form?.message section at the top. It won’t show anything yet, but once we connect the server action in the next section, this is where success messages will appear.

Step 2 — Let’s dissect it line by line

It’s easy to gloss over a form, but each line does something important. Let’s unpack it.

`<form method="POST">`

This is the classic browser pattern. When the user submits, the browser takes every <input> and <textarea> that has a name attribute, packages their values, and sends them in the body of a POST request to the same URL (in this case /contact).

Think of the browser like a mail carrier: the envelope is the POST request, the input names are the addresses on each slip inside, and the values are the contents. Forget the name, and that slip never makes it into the envelope.

`name="..."` on inputs

Absolutely crucial. Without name, the value won’t be sent. Beginners often wonder why their server action isn’t receiving the field — nine times out of ten, it’s because they forgot to add name.

`required` and `type="email"`

These are built-in browser validation helpers. They give the user instant feedback and prevent obviously invalid submissions. But they are not security features. Anyone can bypass them with a custom request. Treat them as UX sugar, not as your guardrails.

`let { form } = $props();`

This line declares a prop called form. SvelteKit automatically passes this prop into your page whenever a form submission is processed by the server. Right now it’s undefined, but soon it will hold messages, errors, and even the previous values the user typed.

`{#if form?.message}`

This conditional block displays a success message only after the server action returns one. Before submission, nothing renders. After a successful action, you might get form.message = "Thanks, Alice!" and see the ✅ success line appear.

Step 3 — What happens when you click “Send”

Let’s trace the lifecycle without any JavaScript at all:

User fills in the form and clicks Send.
The browser collects the inputs into a FormData object and issues a POST /contact.
SvelteKit checks if there’s a server file called +page.server.ts or +page.server.js at that route. If it exists, it runs the appropriate server action.
That action can validate, save to a database, send emails, or return any data.
SvelteKit then re-renders the page, injecting the returned data into the form prop.

This all works without JavaScript. The cycle is HTML → HTTP → HTML.

And that’s the beauty: your form will work in browsers with JS disabled, on flaky mobile connections, or even in places where your fancy SPA logic might fail. Accessibility and resilience are built in from the start.

Step 4 — Easy mistakes to avoid ⚠️

Even this simple form hides a few pitfalls:

Forgetting name → The server never receives the input. Always double-check every input has a name.
Trusting required → Good for user experience, useless for real security. Server validation is mandatory.
Expecting no reload → At this baseline, a submission reloads the page. That’s normal and good. Later we’ll enhance it with use:enhance.
Putting logic in the client first → Resist the temptation to hook up on:submit and fetch() right away. Let the browser and SvelteKit do the heavy lifting.

Step 5 — Try it yourself 🚀

Let’s get this running in your project. Hands on is the fastest way to learn.
I am sure by this time in the series, you are pro at trying stuff out, but just in case, run command npm run dev from terminal and then open http://localhost:5173/contact. You should see the contact form rendered.

Fill in some fields and click Send. Right now you’ll probably get a 404 or 500 after submit, or form might reload. That’s expected — we haven’t told the server what to do with the POST yet.

The important thing to notice is:

The form renders fine.
Submitting triggers a real POST.
The browser reloads as part of that process.

This proves the baseline works: SvelteKit is listening, and your form is already “real.”

Adding Server Actions and Validation

Right now our contact form renders beautifully and sends a real POST request. But when you hit Send, the server just shrugs — it doesn’t know what to do with that POST yet.

Time to give the server some brains. In SvelteKit, this is done with server actions. Actions are special functions that run only on the server, respond to form submissions, and pass their results back into your page via the form prop.

This is where the magic happens: we can validate the inputs, return friendly error messages, and even save data to a database or send an email.

Step 1 — Create the server file

In the same folder as +page.svelte, add a file called +page.server.ts (or .js if you’re not using TypeScript). This file is where actions live.

📂 File: src/routes/contact/+page.server.js

// src/routes/contact/+page.server.js
import { fail } from '@sveltejs/kit';

// Simple helper to check email format
function isValidEmail(value) {
  return /\S+@\S+\.\S+/.test(value);
}

export const actions = {
  // Default action: runs when the form posts without ?/name
  default: async ({ request }) => {
    const formData = await request.formData();

    // Extract values from <input name="...">
    const name = String(formData.get('name') ?? '').trim();
    const email = String(formData.get('email') ?? '').trim();
    const text = String(formData.get('text') ?? '').trim();

    // Collect errors
    const errors = {};
    if (name.length < 2) errors.name = 'Please enter your name (at least 2 characters).';
    if (!isValidEmail(email)) errors.email = 'Please enter a valid email address.';
    if (text.length < 10) errors.text = 'Message must be at least 10 characters.';

    // If invalid, return errors + values
    if (Object.keys(errors).length > 0) {
      return fail(422, { errors, values: { name, email, text } });
    }

    // Pretend to save the message (DB, email, etc.)
    // await db.messages.create({ name, email, text });

    // Success: return a message
    return { message: `Thanks, ${name}! We received your message.` };
  }
};

Step 2 — Breaking it down

Let’s look closely at what’s happening.

export const actions
An object where each key is an action. Here we only define default. If your form didn’t specify action="?/something", it maps to default.
async ({ request })
Every action receives a parameter that includes the original Request object. We pull it out to get the form data.
await request.formData()
This gives you all the input values as a FormData object. It works exactly like new FormData(formElement) in the browser.
Extracting values
We grab name, email, and text, trim them, and ensure they’re strings. This prevents null from sneaking in if the field is missing.
Validation
We build an errors object. Each property matches the name of a field. If the name is too short, we add errors.name. If the email is invalid, errors.email, etc.
fail(422, data)
The special fail helper tells SvelteKit:
- The submission failed validation.
- The response should have HTTP status 422 (Unprocessable Entity).
- The data object should be injected back into the page’s form prop.
Success case

If there are no errors, we return { message: ... }. That message is now available as form.message inside the page.

This is the full round-trip: form → server → validation → form again.

Step 3 — Update the page to display errors

Let’s hook up the error messages and make sure the form preserves values after a failed submission.

📂 File: src/routes/contact/+page.svelte

<script>
  let { form } = $props();
</script>

<h1>Contact us</h1>

{#if form?.message}
  <p class="success">✅ {form.message}</p>
{/if}

<form method="POST" novalidate>
  <div class="field">
    <label for="name">Your name</label>
    <input id="name" name="name" value={form?.values?.name ?? ''} />
    {#if form?.errors?.name}
      <small class="error">{form.errors.name}</small>
    {/if}
  </div>

  <div class="field">
    <label for="email">Your email</label>
    <input id="email" type="email" name="email" value={form?.values?.email ?? ''} />
    {#if form?.errors?.email}
      <small class="error">{form.errors.email}</small>
    {/if}
  </div>

  <div class="field">
    <label for="text">Message</label>
    <textarea id="text" name="text" rows="5">{form?.values?.text ?? ''}</textarea>
    {#if form?.errors?.text}
      <small class="error">{form.errors.text}</small>
    {/if}
  </div>

  <button type="submit">Send</button>
</form>

<style>
  form {
    display: grid;
    gap: 1rem;
    max-width: 40rem;
  }

  .field {
    display: grid;
    gap: 0.25rem;
  }

  label {
    font-weight: 500;
  }

  input,
  textarea {
    padding: 0.5rem;
    border: 1px solid #ccc;
    border-radius: 0.25rem;
    font-size: 1rem;
  }

  .error {
    color: #c00;
    font-size: 0.875rem;
  }

  .success {
    color: #0a7;
    margin-bottom: 1rem;
  }
</style>

Step 4 — What’s new here

If you are typing along, you can choose to skip the style section, it is just meant to make the form look better than before.

novalidate
This disables the browser’s built-in validation popups. Why? Because we want to test and see our server-side errors clearly. In production, you can combine both if you want.
value={form?.values?.name ?? ''}
This ensures the field is prefilled with what the user typed, even if validation failed. Without this, every failed submit would wipe out their input — incredibly frustrating.
{#if form?.errors?.field}
Shows error messages right next to each field. This makes the form user-friendly and accessible.

Step 5 — The lifecycle now

Here’s the new flow:

User submits.
Browser sends POST → server action runs.
Server validates.

If errors: fail(422, { errors, values }) returns.
If success: { message: "Thanks…" } returns.
1. SvelteKit re-renders the page with the returned object as form.
2. Page shows either:
Inline errors while preserving what the user typed, or
A success message. (with form values cleared out)

The cycle is smooth and reliable, all with basic HTML forms.

Step 6 — Why preserving values matters

Imagine typing a 200-character support request, only to have it vanish because your email field had a typo. You’d be furious.

By returning values in the fail response, and feeding them back into each field, we avoid that frustration. The user just corrects the email and resubmits. This little detail makes forms feel professional.

Try it out

Test it at http://localhost:5173/contact:

Submit without typing → error messages under each field.
Enter a short name or invalid email → only that field shows an error.
Enter valid values → page reloads and shows the success message.

Congratulations — you’ve now built a real, validated form that works without JavaScript and handles errors gracefully.

Step 8 — Recap

We created a server action in +page.server.ts.
It extracted form values, validated them, and returned either errors or a success message.
We updated the page to display inline errors and preserve input values.
We now have a complete form loop: submit → validate → feedback.

This is already production-ready in many apps. But we can make it even smoother with progressive enhancement — letting SvelteKit handle submissions via fetch when JavaScript is available. That’s what we’ll do next.

Progressive Enhancement, Redirects, File Uploads & a Mini-Project

At this point, we have a solid form foundation:

Works with or without JavaScript.
Validates data on the server.
Shows inline errors and preserves what the user typed.

That’s already enough to ship. But with JavaScript enabled, we can do even better:

Submissions don’t need to reload the whole page.
We can show a loading state while waiting.
We can redirect smoothly after success.
We can even upload files or handle multiple actions from one page.

This is where progressive enhancement comes in. Instead of replacing the HTML form, we enhance it when JavaScript is available.

Step 1 — Meet `use:enhance`

SvelteKit ships with a helper called enhance from $app/forms. All you do is attach it to a form:

📂 File: src/routes/contact/+page.svelte

<!-- src/routes/contact/+page.svelte -->
<script>
  import { enhance } from '$app/forms';
  let { form } = $props();
</script>

<form method="POST" use:enhance>
  <label>
    Your name
    <input name="name" required />
  </label>
  <label>
    Your email
    <input type="email" name="email" required />
  </label>
  <label>
    Message
    <textarea name="text" rows="5" required></textarea>
  </label>
  <button type="submit">Send</button>
</form>

That’s it — one extra attribute.

What’s happening here?

With JavaScript disabled → nothing changes. The form does a classic POST, the server action runs, and the whole page reloads to show the result.
With JavaScript enabled but no use:enhance → still the same: full reload after submit, scroll resets, local UI state (like open menus) disappears.
With JavaScript enabled + use:enhance → now SvelteKit intercepts the submit in JavaScript:
- The form data is sent with fetch.
- The server action runs exactly as before.
- The response (errors, values, or success) is patched into the current page via the form prop.
- No full reload — just a seamless update.

Why does this matter?

No flash or flicker of a reload.
Scroll position stays put.
Other interactive UI doesn’t reset.
Errors and success messages feel instant.
And your server code is unchanged.

This is progressive enhancement: keep the rock-solid baseline that works everywhere, and add smoothness when JavaScript is available.

💡 Pro tip: If you open DevTools → Network tab, you’ll still see a POST request fire off. That’s normal! The difference is that SvelteKit handles it with fetch and patches the page in place, instead of letting the browser throw everything away and reload from scratch.

Step 2 — Add a pending/loading state

Enhancement is cool, but users also need feedback while waiting. That’s where a custom callback comes in. The enhance function lets you intercept what happens around the form submission: you can flip flags, show spinners, scroll somewhere, even prevent the default update if you want.

📂 File: src/routes/contact/+page.svelte

<!-- src/routes/contact/+page.svelte -->
<script>
  import { enhance } from '$app/forms';
  let { form } = $props();
  let submitting = $state(false);
</script>

<form
  method="POST"
  use:enhance={() => {
    // This code runs right when the form is submitted
    submitting = true;

    // Return a callback that runs after the server responds
    return async ({ update }) => {
      await update(); // apply the server's response to `form`
      submitting = false;
    };
  }}
>
  <label>
    Your name
    <input name="name" required />
  </label>
  <label>
    Your email
    <input type="email" name="email" required />
  </label>
  <label>
    Message
    <textarea name="text" rows="5" required></textarea>
  </label>
  <button disabled={submitting}>
    {submitting ? 'Sending…' : 'Send'}
  </button>
</form>

What’s happening here?

When you write use:enhance(fn), SvelteKit:

Hooks into the form’s submit event.
Calls your function (fn) right before it sends data to the server.

That’s why we set submitting = true immediately.
1. Your function returns another function — a handler that receives an { update } object once the server responds.
2. Calling await update() tells SvelteKit: “okay, apply the server’s response to the form prop, just like a normal submission would.”
3. After that finishes, we set submitting = false to re-enable the button.

Why this matters

Without this callback, SvelteKit would still enhance the form, but you wouldn’t know when the request was “in flight.”
With it, you can add loading indicators, disable buttons, or do anything else that makes the app feel alive.
Errors and success still flow into form automatically — we’re just giving the user a friendly “Sending…” while they wait.

💡 Reminder: In this snippet we’re focusing only on the loading state. If you also keep the error-handling markup from earlier (form.errors, form.values), it continues to work alongside use:enhance.

Step 3 — Redirect after success

Sometimes you don’t want to stay on the same page after submission — for example, a contact form usually goes to a thank-you page. That’s the Post/Redirect/Get pattern.

📂 File: src/routes/contact/+page.server.js

Up to now, on success you probably had something like this in your server action:

// success: return a message
return { message: `Thanks, ${name}! We received your message.` };

👉 Replace that line with a redirect:

// success: redirect to thank-you page
throw redirect(303, '/contact/thanks');

Everything else in your action — validation, error handling, preserving values — stays exactly the same.

📂 File: src/routes/contact/thanks/+page.svelte

<!-- src/routes/contact/thanks/+page.svelte -->
<h1>Thanks!</h1>
<p>We’ll be in touch soon.</p>

💡 Why 303?
Because it tells the browser: “This POST is complete, now do a GET on that page.” That avoids the classic “Do you want to resubmit this form?” warning if the user refreshes.

⚠️ Heads-up: In this demo we’re only focusing on the redirect. If your form submission fails validation (e.g. the message is too short), you won’t see error messages unless you keep the error-handling markup from earlier. So for now, make sure you submit valid data to see the redirect in action.

Step 4 — File uploads 📎

File inputs work just like any other input. The only difference is you need enctype="multipart/form-data" on the form. On the server, files arrive as File objects.

📂 File: src/routes/profile/+page.svelte

<!-- src/routes/profile/+page.svelte -->
<script>
  import { enhance } from '$app/forms';
  let { form } = $props();
</script>

<h1>Upload your profile picture</h1>

{#if form?.uploaded}
  <p class="success">✅ Upload complete!</p>
{/if}

{#if form?.error}
  <p class="error">⚠️ {form.error}</p>
{/if}

<form method="POST" enctype="multipart/form-data" use:enhance>
  <input type="file" name="avatar" accept="image/*" required />
  <button>Upload</button>
</form>

<style>
  .success { color: #0a7; margin-top: 1rem; }
  .error { color: #c00; margin-top: 1rem; }
</style>

📂 File: src/routes/profile/+page.server.js

// src/routes/profile/+page.server.js
import { fail } from '@sveltejs/kit';

export const actions = {
  default: async ({ request }) => {
    const data = await request.formData();
    const file = data.get('avatar');

    if (!(file instanceof File)) {
      return fail(400, { error: 'No file uploaded' });
    }

    // Example: read into memory (works for small files)
    const bytes = new Uint8Array(await file.arrayBuffer());
    // await storage.put('avatar.png', bytes);

    return { uploaded: true };
  }
};

How it works

The form in +page.svelte POSTs to the server with multipart/form-data.
The action in +page.server.js receives the file as a File object.
If no file is uploaded → return fail(400, { error: … }).
If the file is valid → return { uploaded: true }.
That response is passed into the form prop, so {#if form?.uploaded} or {#if form?.error} show feedback to the user.

⚠️ Note: In this demo we’re reading the entire file into memory. That’s fine for small files, but for larger ones you should stream directly to disk or cloud storage.

Mini-Project: Profile Manager 👤

Time to bring it all together!
So far, we’ve learned about forms, validation, progressive enhancement, pending/loading states, redirects, and even file uploads. Let’s wrap those pieces into a mini-project: a profile manager.

Here’s what the app will do:

Let a user fill in their name and bio.
Let them upload a profile picture.
If the form has errors → show them inline and preserve the values.
If submission succeeds → show a “Profile updated” message and a live preview of the saved profile.
While uploading → disable the button and show “Saving…” so users know something’s happening.
And because we’re still using plain <form> underneath, it works with or without JavaScript.

Client page

📂 File: src/routes/profile/+page.svelte

<!-- src/routes/profile/+page.svelte -->
<script>
  import { enhance } from '$app/forms';
  let { form } = $props();
  let submitting = $state(false);
</script>

<h1>Edit your profile</h1>

{#if form?.success}
  <p class="success">✅ Profile updated!</p>
{/if}

<form
  method="POST"
  enctype="multipart/form-data"
  use:enhance={() => {
    submitting = true;
    return async ({ update }) => {
      await update(); // apply server response to `form`
      submitting = false;
    };
  }}
>
  <div class="field">
    <label for="name">Name</label>
    <input
      id="name"
      name="name"
      value={form?.values?.name ?? ''}
      required
    />
    {#if form?.errors?.name}
      <small class="error">{form.errors.name}</small>
    {/if}
  </div>

  <div class="field">
    <label for="bio">Bio</label>
    <textarea
      id="bio"
      name="bio"
      rows="3"
    >{form?.values?.bio ?? ''}</textarea>
    {#if form?.errors?.bio}
      <small class="error">{form.errors.bio}</small>
    {/if}
  </div>

  <div class="field">
    <label for="avatar">Profile picture</label>
    <input id="avatar" type="file" name="avatar" accept="image/*" />
    {#if form?.errors?.avatar}
      <small class="error">{form.errors.avatar}</small>
    {/if}
  </div>

  <button type="submit" disabled={submitting}>
    {submitting ? 'Saving…' : 'Save profile'}
  </button>
</form>

{#if form?.url}
  <h2>Preview</h2>
  <img src={form.url} alt="Uploaded avatar" class="avatar" />
  <p><strong>{form?.values?.name}</strong></p>
  <p>{form?.values?.bio}</p>
{/if}

<style>
  form { display: grid; gap: 1rem; max-width: 30rem; }
  .field { display: grid; gap: 0.25rem; }
  .error { color: #c00; font-size: 0.875rem; }
  .success { color: #0a7; margin: 1rem 0; }
  .avatar {
    display: block;
    margin-top: 1rem;
    max-width: 200px;
    border-radius: 0.5rem;
  }
</style>

Server action

📂 File: src/routes/profile/+page.server.js

// src/routes/profile/+page.server.js
import { fail } from '@sveltejs/kit';
import fs from 'fs/promises';
import path from 'path';

export const actions = {
  default: async ({ request }) => {
    const data = await request.formData();

    const name = String(data.get('name') ?? '').trim();
    const bio = String(data.get('bio') ?? '').trim();
    const avatar = data.get('avatar');

    // Collect validation errors
    const errors = {};
    if (name.length < 2) errors.name = 'Name must be at least 2 characters.';
    if (bio.length > 200) errors.bio = 'Bio must be under 200 characters.';
    if (avatar && !(avatar instanceof File)) {
      errors.avatar = 'Invalid file.';
    }

    if (Object.keys(errors).length > 0) {
      return fail(422, { errors, values: { name, bio } });
    }

    let url = null;
    if (avatar instanceof File && avatar.size > 0) {
      try {
        // Ensure uploads folder exists
        const uploadDir = path.join('static', 'uploads');
        await fs.mkdir(uploadDir, { recursive: true });

        // Save file with a timestamp to avoid collisions
        const filename = `avatar-${Date.now()}-${avatar.name}`;
        const filePath = path.join(uploadDir, filename);

        const bytes = new Uint8Array(await avatar.arrayBuffer());
        await fs.writeFile(filePath, bytes);

        url = `/uploads/${filename}`;
      } catch (e) {
        // Catch server-side issues (permissions, disk, etc.)
        return fail(500, {
          error: 'File upload failed. Please try again later.',
          values: { name, bio }
        });
      }
    }

    return {
      success: true,
      url,
      values: { name, bio }
    };
  }
};

How it works

Form POSTs with multipart/form-data.
Validation runs on the server: name length, bio length, avatar sanity.
Errors → returned with fail(422, …), displayed inline under each field.
Valid submission → avatar saved into /static/uploads/, URL returned.
Enhancement (use:enhance) ensures the form updates without reload when JS is enabled, while still working with reload if JS is disabled.
On success, the updated profile (name, bio, and uploaded image) is displayed immediately on the same page.
If something goes wrong while saving the file (e.g. no write permission), the try/catch ensures users see a friendly error instead of a raw 500.

⚠️ Production notes

This demo is great for learning, but in real apps you’ll want to:

Use proper storage (e.g. S3, Cloudflare R2, or a database), not just dump files in /static.
Sanitize filenames to prevent unsafe paths.
Limit file size and type to protect your server.

Step 7 — Best practices ⚠️

Always validate on the server — never trust client-side input alone.
Use fail(status, data) to return validation errors and preserve form values.
Default vs named actions: use a single default for simple cases, or multiple named actions (?/create, ?/delete) when one page needs more than one form.
After a successful POST, redirect with 303 (Post/Redirect/Get) to avoid the dreaded “resubmit form” warning.
If you add a custom enhance callback, keep it small and always call update() so the server response is applied.
For file uploads: stream large files (pipe them directly to disk or cloud storage) instead of buffering them into memory.
Consider rate-limiting expensive actions (like sending emails or heavy database writes) so a spammy user can’t overload your app.

Wrapping up 🎉

We started with the most boring form imaginable — plain old HTML. Step by step we layered on:

Server actions with real validation.
Friendly error handling that preserves what users typed.
Progressive enhancement with use:enhance.
Pending/loading states for optimistic UX.
Redirects using the PRG pattern.
File uploads (with previews!).
A mini Profile Manager project that tied it all together.

This gives you the full picture of forms in SvelteKit: start with a rock-solid, accessible baseline that works without JavaScript, and then progressively enhance it into something that feels fast and modern when JS is available.

Your forms are now both robust and delightful — exactly what users (and developers) want. 🎉

Next up: Mastering Svelte Custom Stores

SvelteKit Routing Tutorial: Layouts, Nested Routes & Multi-Page Apps

Ali Aslam — Tue, 09 Sep 2025 13:48:15 +0000

Building apps usually starts simple: one page, one screen, one set of components. But let’s be honest — no real-world app stays that way.

Even the most basic website has multiple pages:

Home → /
About → /about
Blog → /blog/[slug]
Dashboard → /dashboard/settings

Different pages mean different layouts, different content, and sometimes different data. And if you’ve ever wired this up by hand (hello React Router configs 👋), you know it can get complicated fast: JSON route maps, nested paths, boilerplate everywhere.

That’s exactly where SvelteKit comes to the rescue.
With file-based routing, the filesystem is your router. No configs, no fuss — just drop files in src/routes and your pages come alive.

If you’re brand new to SvelteKit, I’ve got a setup & project structure guide that walks through scaffolding a project, exploring folders, and dipping a toe into basic routing and layouts. Some of what we cover here will feel familiar — but this time we’re going deeper into the good stuff:

Build routes using the filesystem
Use layouts for shared UI (navbars, footers, etc.)
Create nested routes (like /dashboard/settings)
Add dynamic parameters (like /blog/[slug])
Handle 404s and fallbacks

🎉 Let’s dive in.

Step 1: The `routes` Folder

Open a fresh SvelteKit app. Inside src/, you’ll see a routes folder.
This folder is special: every file inside automatically becomes a route.

For example:

src/
└─ routes/
   ├─ +page.svelte
   ├─ about/
   │   └─ +page.svelte
   └─ contact/
       └─ +page.svelte

This gives you:

/ → served by routes/+page.svelte
/about → served by routes/about/+page.svelte
/contact → served by routes/contact/+page.svelte

No config files, no routing libraries. 🚀 Just files and folders.

Step 2: `+page.svelte`

Every page is just a Svelte component named +page.svelte.

For example, let’s make an “About” page:

File: src/routes/about/+page.svelte

<script>
  const team = $state(['Ada', 'Grace', 'Linus']);
</script>

<h1>About Us</h1>
<ul>
  {#each team as member}
    <li>{member}</li>
  {/each}
</ul>

Now, when you visit /about, you’ll see this page.

That’s the magic: SvelteKit takes care of wiring the route to the file automatically.

⚠️ Pitfall: Don’t rename the file. It must be +page.svelte. If you call it About.svelte, it won’t be routed.

👉 I recommend following along and typing this out yourself. Writing code by hand is the fastest way to lock the concepts into muscle memory — way better than just skimming.

Step 3: Layouts — Shared UI

Most apps share some common structure across pages:

Navbars
Footers
Sidebars

Without layouts, you’d have to duplicate those elements in every +page.svelte. That gets repetitive.

Instead, SvelteKit lets you define a layout with +layout.svelte.

Example structure:

src/routes/
├─ +layout.svelte
├─ +page.svelte
├─ about/
│   └─ +page.svelte
└─ contact/
    └─ +page.svelte

File: src/routes/+layout.svelte

<script>
  // Svelte passes the child page into a special `children` prop
  let { children } = $props();
</script>

<nav>
  <a href="/">Home</a>
  <a href="/about">About</a>
  <a href="/contact">Contact</a>
</nav>

{@render children()}

Everything in +layout.svelte renders around your pages.
children is the placeholder for the child page content (this is the modern replacement for <slot />).

So now:

/about → shows the navbar + About page content.
/contact → shows the navbar + Contact page content.

✅ One layout, shared across all pages.

⚠️ Pitfall: If you forget {@render children()}, your child page won’t render at all.

Why we’re revisiting this

If you followed the setup article, layouts may look familiar. The difference here is that we’ll build on this concept — exploring scoping and nesting, which unlock patterns like dashboards with their own sidebars or sections with unique headers.

A quick note on scoping

Layouts only apply to the folder they’re in (and its children). A top-level +layout.svelte wraps the whole app, while a +layout.svelte inside routes/dashboard/ applies only to /dashboard/*.

This scoped behavior is what allows nested layouts to work — stacking a global navbar with section-specific UIs.

Step 4: Nested Layouts

Sometimes a global layout isn’t enough. You might want a section-specific look — like a dashboard with its own header and menu, separate from your site-wide navbar.

The cool part? SvelteKit makes this dead simple. You just drop another +layout.svelte inside a subfolder, and boom: nested layouts.

src/routes/
├─ +layout.svelte          # global layout
├─ dashboard/
│   ├─ +layout.svelte      # dashboard layout
│   ├─ +page.svelte        # /dashboard
│   └─ settings/
│       └─ +page.svelte    # /dashboard/settings

File: src/routes/dashboard/+layout.svelte

<script>
  let { children } = $props();
</script>

<h1>Dashboard</h1>
<nav>
  <a href="/dashboard">Overview</a>
  <a href="/dashboard/settings">Settings</a>
</nav>

{@render children()}

Now, when you visit /dashboard/settings, you’ll see three layers of UI stacked together:

The global layout (e.g. your site-wide navbar).
The dashboard layout (dashboard header + menu).
The settings page content.

💡 This nesting can go as deep as you want. Want a settings/security/ section with its own sidebar? No problem — just add another layout.

⚠️ Pitfall: If your layouts get too deeply nested, it can feel like Russian dolls. Keep an eye on complexity — sometimes a reusable component is a better fit than yet another layout.

Step 5: Nested Routes

Layouts handle shared UI, but what about pages inside pages? That’s where nested routes come in.

Every subfolder inside src/routes/ is automatically a nested route. You don’t configure anything — folder = path.

Example structure:

src/routes/blog/
├─ +page.svelte           # /blog
└─ first-post/
   └─ +page.svelte        # /blog/first-post

File: src/routes/blog/+page.svelte

<h1>Blog Index</h1>
<a href="/blog/first-post">Read first post</a>

File: src/routes/blog/first-post/+page.svelte

<h1>First Blog Post</h1>
<p>This is my first post!</p>

When you visit /blog/first-post, SvelteKit stitches everything together automatically — no route config, no imports, just folders and files. 🚀

💡 Pro tip: nested routes play really well with nested layouts. For example, you can give your entire /blog/* section a shared layout (say, a blog sidebar), and then each post page gets that for free.

⚠️ Pitfall: avoid going folder-happy. While it’s tempting to mirror your entire sitemap in folders, keep things organized but not over-engineered.

Step 6: Dynamic Routes

Static routes are great when you know them in advance (/about, /contact, /pricing).

But for things like blog posts, products, or user profiles, you don’t know every possible URL ahead of time. You can’t make a new folder for every single post or user. That’s where dynamic routes save the day.

In SvelteKit, you make one by putting a folder name in square brackets:

src/routes/blog/[slug]/+page.svelte

👉 Important: you literally name the folder [slug].

In the filesystem → [slug] is the folder name.
In the browser → you replace it with a real value, like /blog/hello-svelte.

File: src/routes/blog/[slug]/+page.svelte

<script>
  let { params } = $props();
</script>

<h1>Blog Post: {params.slug}</h1>

Now if you visit:

/blog/hello-svelte → params.slug === "hello-svelte"
/blog/my-second-post → params.slug === "my-second-post"

✅ With one file, you just unlocked an infinite number of routes.

💡 Pro tip: You can even chain multiple params:

src/routes/blog/[year]/[slug]/+page.svelte

Which maps to URLs like /blog/2025/hello-svelte.

⚠️ Don’t overuse dynamic routes — if you only ever need /about and /contact, just make static files.

Step 7: Loading Data in SvelteKit

A page without data is like a sandwich without filling — looks fine, but it won’t satisfy anyone. 🥪

That’s why in SvelteKit, data loading is built into the routing system.

Next to your +page.svelte, you can add a +page.js (or +page.server.js). Inside, you define a load function. Whatever load returns becomes available inside your page as the data prop.

Example:

File: src/routes/profile/+page.js

export async function load() {
  return {
    user: { name: "Ada Lovelace", bio: "Mathematician & first programmer" }
  };
}

File: src/routes/profile/+page.svelte

<script>
  let { data } = $props();
</script>

<h1>{data.user.name}</h1>
<p>{data.user.bio}</p>

When you open /profile, you’ll see Ada’s info — no extra fetch boilerplate, no manual prop passing.

Why this is awesome:

Universal by default → runs on the server first, then in the client when navigating.
SEO + performance friendly → pages ship fully rendered.
Clean separation → UI in one file, data logic in another.

👉 We’ll later explore when to use +page.js vs +page.server.js. For now, just know: load is how data flows into your pages.

Step 8: Universal `load` — Runs on Server and Client

Now let’s combine what we’ve learned so far:

Dynamic routes (Step 6)
Data loading (Step 7)

We’ll build a mini blog with two pages:

/blog → shows a list of posts.
/blog/[slug] → shows an individual post.

File Structure

src/routes/blog/
├─ +page.svelte        # blog index page
├─ +page.js            # loads list of posts
└─ [slug]/             # dynamic route for individual posts
   ├─ +page.svelte     # single post page
   └─ +page.js         # loads one post

Blog Index Page

File: src/routes/blog/+page.js

export async function load() {
  return {
    posts: [
      { slug: "hello-svelte", title: "Hello Svelte" },
      { slug: "my-second-post", title: "My Second Post" }
    ]
  };
}

File: src/routes/blog/+page.svelte

<script>
  let { data } = $props();
</script>

<h1>Blog</h1>
<ul>
  {#each data.posts as post}
    <li><a href={`/blog/${post.slug}`}>{post.title}</a></li>
  {/each}
</ul>

Visiting /blog now shows a list of links like:

“Hello Svelte” → /blog/hello-svelte
“My Second Post” → /blog/my-second-post

Individual Post Page

File: src/routes/blog/[slug]/+page.js

import { error } from '@sveltejs/kit';

export async function load({ params }) {
  const posts = {
    "hello-svelte": { title: "Hello Svelte", content: "This is my first post." },
    "my-second-post": { title: "My Second Post", content: "Here’s some more content." }
  };

  const post = posts[params.slug];

  if (!post) {
    throw error(404, `Post "${params.slug}" not found`);
  }

  return { post };
}

File: src/routes/blog/[slug]/+page.svelte

<script>
  let { data } = $props();
</script>

<article>
  <h2>{data.post.title}</h2>
  <p>{data.post.content}</p>
</article>

Here’s what’s happening:

The [slug] folder means the URL segment is dynamic.
Visiting /blog/hello-svelte makes params.slug === "hello-svelte".
The loader uses that slug to fetch the right post.
If the slug doesn’t exist, we throw error(404) to show a not-found page instead of crashing.

How to Test It 🚦

Start your dev server:

   npm run dev

Visit /blog → you’ll see the list of posts.
Click a link → you’ll see the full post.

On the first load, load runs on the server, so the HTML already contains the post content → faster first paint + SEO-friendly.
On client-side navigation, the same load runs in the browser using fetch.

Try visiting /blog/not-a-post → you’ll get a proper 404 instead of a 500.

✨ That’s universal loading in action: one load function, and SvelteKit decides whether it runs server-side or client-side depending on how the user navigates.

Step 9: Server-Only Loading 🔒

Sometimes you really do need secrets — like database queries, authentication, or API keys. That’s where +page.server.js comes in.

This works just like +page.js, but with one crucial difference: it only ever runs on the server. That means the code never reaches the browser.

Example

🧹 Quick cleanup: If you’ve just done Step 8, you already have a +page.js inside /blog/[slug]. Before trying this step, remove that file (or rename it) and replace it with +page.server.js. Otherwise, SvelteKit will ignore the universal loader and only run the server one.

File: src/routes/blog/[slug]/+page.server.js

import { error } from '@sveltejs/kit';

export async function load({ params }) {
  const posts = {
    "hello-svelte": {
      title: "Hello Svelte",
      content: "This post is loaded server-side only. Imagine pulling it from a database 🔒"
    },
    "my-second-post": {
      title: "My Second Post",
      content: "Another server-only post. Safe for secrets, safe for API keys."
    }
  };

  const post = posts[params.slug];

  if (!post) {
    throw error(404, `Post "${params.slug}" not found`);
  }

  return { post };
}

Notice how we’re serving different content depending on the slug.
And since this runs only on the server, you could safely query a DB or use environment variables here.

Using the data in the page

Whatever you return from +page.server.js is available in the page as the data prop — exactly the same as before.

File: src/routes/blog/[slug]/+page.svelte

<script>
  let { data } = $props();
</script>

<article>
  <h1>{data.post.title}</h1>
  <p>{data.post.content}</p>
</article>

Now:

/blog/hello-svelte → shows “Hello Svelte” with custom content.
/blog/my-second-post → shows “My Second Post” with its own text.
/blog/not-a-post → gives you a proper 404.

Why use `+page.server.js` here?

Protecting secrets → fetching blog posts from an API with a private key? This keeps it safe.
Server capabilities → connect to databases, check user sessions, or use environment variables.
Same flow as before → whatever you return from load still becomes available to your page as data.

Key difference vs. `+page.js`

+page.js → runs on both server (first load) and client (navigations).
+page.server.js → runs only on the server.

Think of it like this:

Public data → +page.js
Private or sensitive data → +page.server.js

⚠️ Pitfall: Don’t try to use browser-only stuff (window, document, localStorage, etc.) inside +page.server.js. They don’t exist on the server.

👉 This way, you’ve now seen both sides: universal loaders for public data (Step 8), and server-only loaders for protected data (Step 9).

Step 10: Props vs `data`

Whatever your load function returns is automatically passed into your page as a special prop called data. You don’t import it, you don’t pass it manually — SvelteKit wires it up for you.

Example:

// inside +page.js or +page.server.js
export async function load() {
  return {
    user: { name: 'Ada' }
  };
}

File: src/routes/profile/+page.svelte

<script>
  let { data } = $props();
</script>

<p>Hello {data.user.name}</p>

Destructuring for convenience

If you only need part of the object, you can pull it out right away:

<script>
  let { data } = $props();
  const { user } = data;
</script>

<p>Hello {user.name}</p>

This is just shorthand. Both versions work the same — destructuring just saves a bit of typing when you’re accessing the same field multiple times.

Why this matters

data is the bridge between your loader and your page.
You never import things directly from +page.js or +page.server.js into your component — SvelteKit takes care of that.
This keeps your UI and data fetching logic separate, which makes your app easier to maintain and reason about.

💡 Pro tip: If your data object starts looking like a giant “junk drawer” of unrelated values, that’s usually a sign you should split the page into smaller routes or use multiple loaders.

Step 11: The Special `fetch`

Normally, fetching data in JavaScript means juggling different environments:

In the browser, you’d use window.fetch.
On the server, you’d need something like node-fetch.

That’s a pain to maintain.

👉 Inside SvelteKit’s load function, you get a special fetch that works the same everywhere.

On the server → it behaves like node-fetch.
On the client → it behaves like the browser’s fetch.

This makes your data loading code universal and portable — you write it once, and SvelteKit takes care of the environment.

Example:

File: src/routes/products/+page.js

export async function load({ fetch }) {
  const res = await fetch('/api/products.json');
  const products = await res.json();

  return { products };
}

Now whether the page is first rendered on the server or navigated to in the client, it’ll Just Work™.

✅ You don’t need to worry about environment differences — the fetch is already adapted for you.

💡 Pro tip: always use this provided fetch inside load. It plays nicely with SvelteKit features like credentials, relative paths, and even preloading.

Step 12: Error Handling in `load`

Of course, not every fetch succeeds. APIs fail, typos happen, and sometimes pages just don’t exist.

In SvelteKit, the way to handle errors is to throw an error inside your load function.

import { error } from '@sveltejs/kit';

export async function load({ params, fetch }) {
  const res = await fetch(`/api/posts/${params.slug}.json`);

  if (!res.ok) {
    throw error(404, 'Post not found');
  }

  return { post: await res.json() };
}

Here’s what happens:

If the fetch fails, we throw error(404, 'Post not found').
SvelteKit immediately stops the loader and shows an error page.
By default, it’ll use the global error page.
But if you put a +error.svelte file in the same folder, SvelteKit will use that instead — so you can show a nice custom message.

✅ This means you don’t have to handle errors manually in your component — the framework has your back.

⚠️ Pitfall: don’t try to return an error object yourself (like { error: 'Not found' }). Unless you throw, SvelteKit won’t know to treat it as an actual error page.

Step 14: Universal vs Server `load` — When to Use Which?

Okay, we’ve seen two flavors of load:

Universal (+page.js) → runs on server and client.
Server-only (+page.server.js) → runs only on the server.

So… when do you pick one over the other?

Here’s a simple rule of thumb:

File: src/routes/blog/[slug]/+page.js

// Universal load
export async function load({ params, fetch }) {
  const res = await fetch(`/api/posts/${params.slug}.json`);
  return { post: await res.json() };
}

Use +page.js when:

The data is safe for the client.
You want the same fetch logic to work both server-side and client-side.
Example: blog posts from a public API.

File: src/routes/dashboard/+page.server.js

// Server-only load
export async function load({ locals }) {
  // Pretend this checks a logged-in user from the session
  if (!locals.user) {
    return { user: null };
  }
  return { user: locals.user };
}

Use +page.server.js when:

The data is sensitive (like a database query, user info, or private API key).
You need server-only logic (like authentication checks).
Example: dashboards, admin pages, or user profiles.

👉 Think of it like this:

+page.js → public data (okay for anyone to see).
+page.server.js → private data (keep it on the server).

⚠️ Pitfall: if you accidentally put secret logic in +page.js, it’ll run in the browser too — which means users can peek at it. Always ask yourself: should the client be allowed to see this code?

Wrapping Up 🎁

And that’s it! You’ve just leveled up from single-page Svelte toys to building real multi-page apps with SvelteKit. 🚀

Here’s what you can now do with confidence:

Create routes just by making files (the filesystem is the router).
Share UI across pages with layouts.
Nest layouts and routes as deep as you like.
Use dynamic routes to handle flexible URLs like /blog/[slug].
Fetch data with both universal loaders and server-only loaders.
Handle errors, redirects, and pass data cleanly into your pages.

At this point, you’ve basically got all the routing + data loading superpowers you need to build serious apps. 💪

But apps aren’t just about reading data — we also need to create, update, and delete stuff. That’s where Forms & Actions come in, and SvelteKit makes them just as seamless (and progressively enhanced by default).

👉 Stay tuned for the next part of this series:
“SvelteKit Forms & Actions — Progressive Enhancement the Easy Way”

Mastering Context and Async Data in Svelte (with Examples)

Ali Aslam — Tue, 09 Sep 2025 06:14:16 +0000

Imagine your boss sends a memo that only the intern at the end of the hall really needs. Instead of walking it over, the boss hands it to every manager in between, who each have to carry it down the chain. None of them care about the memo — but they’re stuck passing it along.

That’s what prop drilling feels like.

The pain: prop drilling 🕳️

Let’s see how this shows up in code. Say we’ve got a layout that defines a theme (light or dark). Deep inside that layout, we’ve got a Logo component that needs to know the theme.

Without context, we’re forced to pass theme as a prop through every level:
📂 src/lib/Logo.svelte

<script>
  export let theme;
</script>

<h1 class={theme}>My App</h1>

📂 src/lib/Header.svelte

<script>
  import Logo from './Logo.svelte';
  export let theme;
</script>

<nav>
  <Logo theme={theme} />
</nav>

📂 src/lib/Layout.svelte

<script>
  import Header from './Header.svelte';
  export let theme = 'light';
</script>

<div class={theme}>
  <Header theme={theme} />
</div>

<style>
  .light { background: #f8f8f8; color: #222; }
  .dark { background: #222; color: #f8f8f8; }
</style>

And to use it:

📂 src/routes/+page.svelte

<script>
  import Layout from '$lib/Layout.svelte';
</script>

<Layout theme="dark" />

The theme gets passed through every single level. Even Header, which doesn’t care about theme, has to pass it along just so Logo can use it.

That’s messy, brittle, and painful to maintain.

Enter context 🎒

Prop drilling makes components pass values around like a game of hot potato. Context fixes that by letting a parent set a value once, and any child (no matter how deep) can grab it directly.

Technically, Svelte gives us two helpers:

setContext(key, value) → called in a parent to provide.
getContext(key) → called in a child to consume.

Both must agree on the key (a string or symbol).

To make this nicer, we usually wrap the logic in a special component called a provider. The provider’s job is simple:

Set some context once.
Render its children inside.
Let those children access the context without any prop-drilling.

We’ll build a ThemeProvider that manages a light/dark theme and makes it available to any nested component.

Example: ThemeProvider + ThemedButton

Let’s rewrite the messy example with context.

📂 src/lib/ThemeProvider.svelte

<script>
  import { setContext } from 'svelte';
  import { writable } from 'svelte/store';

  const theme = writable('light');
  setContext('theme', theme);

  function toggle() {
    $theme = $theme === 'light' ? 'dark' : 'light';
  }

  // Extract the `children` snippet from props
  let { children } = $props();
</script>

<div class={$theme}>
  <button onclick={toggle}>Toggle Theme</button>

  {@render children?.()}
</div>

<style>
  .light { background: #f8f8f8; color: #222; padding: 1rem; }
  .dark  { background: #222; color: #f8f8f8; padding: 1rem; }
</style>

Here’s what’s happening:

We create a writable theme store.
We stash it in context under the key "theme".
The provider shows a toggle button to switch between themes.
Whatever components you nest inside <ThemeProvider> get rendered via {children}, and they all have access to the theme context.

The name ThemeProvider can be anything, the convention is to use the suffix 'Provider' in such cases. Real magic is the setContext part.

📂 src/lib/ThemedButton.svelte

<script>
  import { getContext } from 'svelte';

  // grab the store from context
  const theme = getContext('theme');
</script>

<button class={$theme}>
  I just follow the theme!
</button>

<style>
  .light { background: white; color: black; }
  .dark  { background: black; color: white; }
</style>

This button doesn’t take a theme prop. Instead, it asks:

“Hey, is there a theme in context?”

Because it’s wrapped by ThemeProvider, the answer is yes — and it reacts automatically when the theme changes.

Trying it out

📂 src/routes/+page.svelte

<script>
  import ThemeProvider from '$lib/ThemeProvider.svelte';
  import ThemedButton from '$lib/ThemedButton.svelte';
</script>

<h1>Context Demo</h1>

<ThemeProvider>
  <p>This text is inside the provider.</p>
  <ThemedButton />
</ThemeProvider>

Run this, and you’ll see:

A theme container with toggle button.
Themed text + button inside.
When you toggle, all children react automatically.

Now the flow is clear:

ThemeProvider sets up the theme and provides it.
Anything wrapped inside <ThemeProvider> becomes its child.
Those children can grab the theme with getContext('theme').
Toggling updates the theme everywhere at once.

No more props passed down through five layers. Just context.

Why store in context instead of plain values?

You could setContext('theme', 'light'). That works for static values.
But with a store:

Parents can update it ($theme = ...).
Children auto-subscribe with $theme.
Everyone stays in sync.

So the usual pattern is: put a store in context.

When to use what?

Here’s the decision tree:

Props → local, simple parent → child communication.
Stores → global state, accessible from anywhere.
Context → scoped shared state, only within a subtree.

Think of it like this:

Props = direct conversation.
Stores = bulletin board in the office.
Context = team backpack 🎒 that only your squad carries.

Async Data

We’ve got context under our belt. Now let’s switch gears: apps don’t live on islands.
They need data from APIs, databases, or local files. And that data doesn’t always arrive instantly — it’s async.

Why async data feels different

When you fetch data, there are always three states to think about:

Loading — waiting for the response.
Success — data arrived.
Error — something went wrong.

If you don’t handle all three, your UI either looks broken or leaves users staring at a blank screen.

Svelte gives us a built-in tool to manage these states: the {#await} block.

The `{#await}` block

JavaScript’s fetch() returns a promise — a value that isn’t ready yet but will be in the future.
Instead of juggling loading flags and try/catch, Svelte lets you declare all three states inline.

📂 src/lib/JokeFetcher.svelte

<script>
  // Kick off a fetch that returns a promise
  let promise = fetch('https://api.chucknorris.io/jokes/random')
    .then(res => res.json());
</script>

<!-- {#await} handles loading, success, and error in one go -->
{#await promise}
  <p>Loading a hilarious joke…</p>
{:then data}
  <p>{data.value}</p>
{:catch error}
  <p style="color: red">Oops: {error.message}</p>
{/await}

📂 src/routes/+page.svelte

<script>
  import JokeFetcher from '$lib/JokeFetcher.svelte';
</script>

<h1>Joke Demo</h1>
<JokeFetcher />

👉 How it works:

While waiting, the first branch runs → “Loading…”.
When resolved, the data is passed to {:then}.
If rejected, we land in {:catch}.

This means no manual state tracking. The block itself drives the UI.

Refreshing data

So far, the joke loads once when the component mounts. But what if you want a new joke every click?

Solution: wrap the fetch in a function and reassign promise when you need new data.

📂 src/lib/JokeFetcher.svelte

<script>
  let promise;

  function loadJoke() {
    promise = fetch('https://api.chucknorris.io/jokes/random')
      .then(res => res.json());
  }

  // Fetch one on mount
  loadJoke();
</script>

<button onclick={loadJoke}>New Joke</button>

{#await promise}
  <p>Loading…</p>
{:then data}
  <p>{data.value}</p>
{:catch error}
  <p style="color: red">Error: {error.message}</p>
{/await}

📂 src/routes/+page.svelte

<script>
  import JokeFetcher from '$lib/JokeFetcher.svelte';
</script>

<h1>Joke Demo with Refresh</h1>
<JokeFetcher />

Each click starts the cycle again: Loading → Joke → Repeat.

Wrapping async logic in a store

Fetching data directly inside a component works for demos.
But in a real app it quickly gets messy:

You repeat the same fetch logic in multiple places.
Reloading means rewriting the same boilerplate.
Testing/debugging is harder because logic is scattered.

The fix: wrap your async logic in a custom store.
The store owns the fetching logic, tracks state, and exposes results.
Components just consume it.

Step 1 — Create a store

📂 src/lib/userStore.js

import { writable } from 'svelte/store';

export function createUserStore() {
  const { subscribe, set } = writable({
    status: 'loading',
    data: null,
    error: null
  });

  async function load() {
    set({ status: 'loading', data: null, error: null });
    try {
      // fetch a random user between 1 and 10
      const id = Math.floor(Math.random() * 10) + 1;
      const res = await fetch(`https://jsonplaceholder.typicode.com/users/${id}`);
      const data = await res.json();

      set({ status: 'success', data, error: null });
    } catch (err) {
      set({ status: 'error', data: null, error: err });
    }
  }

  // fetch immediately when the store is created
  load();

  return { subscribe, reload: load };
}

What’s happening here?

We create a writable store with three fields: status, data, and error.
The load() function handles the entire fetch cycle:
- Start in "loading" state.
- On success → update with { status: 'success', data }.
- On failure → set { status: 'error', error }.
The store exposes two things:
- subscribe → so components can $subscribe.
- reload → so components can manually trigger a new fetch.

Step 2 — Use it in a component

📂 src/lib/UserProfile.svelte

<script>
  import { createUserStore } from '$lib/userStore.js';

  // create the store
  const user = createUserStore();
</script>

{#if $user.status === 'loading'}
  <p>Loading user...</p>
{:else if $user.status === 'error'}
  <p style="color: red">Error loading user</p>
{:else}
  <h2>{ $user.data.name }</h2>
  <p>Email: { $user.data.email }</p>
  <!-- important: call user.reload, not $user.reload -->
  <button onclick={user.reload}>Reload</button>
{/if}

Key points

$user is the current value of the store (status, data, error).
But reload is a method on the store object itself. That’s why we call user.reload, not $user.reload.
The component doesn’t fetch() at all. It just reacts to $user and calls user.reload() when needed.

Step 3 — Mount it in a page

📂 src/routes/+page.svelte

<script>
  import UserProfile from '$lib/UserProfile.svelte';
</script>

<h1>User Demo</h1>
<UserProfile />

Now when you load the page:

The store immediately fetches a random user.
The component shows Loading → Success/Error.
Clicking Reload fetches another random user.

Combining multiple async calls

Sometimes you need more than one piece of data before rendering.
For example: fetch a user and their posts.

📂 src/lib/UserWithPosts.svelte

<script>
  let promise = Promise.all([
    fetch('https://jsonplaceholder.typicode.com/users/1').then(r => r.json()),
    fetch('https://jsonplaceholder.typicode.com/posts?userId=1').then(r => r.json())
  ]);
</script>

{#await promise}
  <p>Loading user and posts...</p>
{:then [user, posts]}
  <h2>{user.name}</h2>
  <ul>
    {#each posts as post}
      <li>{post.title}</li>
    {/each}
  </ul>
{:catch error}
  <p style="color: red">Failed: {error.message}</p>
{/await}

📂 src/routes/+page.svelte

<script>
  import UserWithPosts from '$lib/UserWithPosts.svelte';
</script>

<h1>User + Posts Demo</h1>
<UserWithPosts />

👉 With Promise.all, you can wait for multiple requests at once.
Notice how {:then [user, posts]} destructures both results directly.

Making loading states nicer: skeletons

Plain “Loading…” text works, but it feels unfinished. Modern UIs use skeletons — animated placeholders that look like content, making the app feel smoother and more polished during loading states.

📂 `src/lib/Skeleton.svelte` (Skeleton Component)

This component simulates loading content with a shimmer effect. It’s customizable and can be adjusted to fit various content sizes (e.g., text, buttons).

<script>
  export let width = '100%';   // Default width to fill the container
  export let height = '2rem';  // Default height for the skeleton
</script>

<!-- Skeleton div -->
<div class="skeleton" style="width: {width}; height: {height};"></div>

<style>
  .skeleton {
    background: linear-gradient(90deg, #f0f0f0, #e0e0e0, #f0f0f0);
    background-size: 200% 100%;  /* Make the shimmer effect visible */
    animation: shimmer 1.5s infinite;  /* Add shimmer effect animation */
    border-radius: 4px;            /* Rounded corners for skeletons */
    margin: 0.5rem 0;              /* Space between skeleton elements */
  }

  @keyframes shimmer {
    0% { background-position: -200% 0; }
    100% { background-position: 200% 0; }
  }
</style>

Shimmer Animation: A shimmering effect that runs infinitely to simulate the loading process.
Customizable Width & Height: You can adjust the width and height of the skeletons to match the content they are replacing (e.g., user name, email, button).
Background Gradient: Creates a smooth visual transition to make the shimmer effect.

📂 `src/lib/UserProfile.svelte` (Using Skeletons)

This component displays the user's profile data or skeletons while loading. It uses the skeletons for elements that are not yet fetched.

<script>
  import { createUserStore } from '$lib/userStore.js';
  import Skeleton from '$lib/Skeleton.svelte';

  const user = createUserStore();  // Initialize the store for fetching user data
</script>

{#if $user.status === 'loading'}
  <!-- Display skeletons when loading -->
  <Skeleton width="60%" height="2rem" />   <!-- Simulate a user name skeleton -->
  <Skeleton width="80%" height="1.5rem" /> <!-- Simulate an email skeleton -->
  <Skeleton width="200px" height="2rem" /> <!-- Simulate a button skeleton -->
{:else if $user.status === 'error'}
  <p style="color: red">Error loading user</p>
{:else}
  <!-- Display actual content when loaded -->
  <h2>{ $user.data.name }</h2>
  <p>Email: { $user.data.email }</p>
  <button onclick={user.reload}>Reload</button>
{/if}

Loading State: Skeletons are shown when the status is 'loading'.
Error Handling: If there's an error, a message is displayed.
Actual Content: When data is successfully fetched, the actual user details are displayed.

📂 `src/routes/+page.svelte` (Page Component)

This file includes the UserProfile component and displays it within the page.

<script>
  import UserProfile from '$lib/UserProfile.svelte';
</script>

<h1>User with Skeleton Demo</h1>
<UserProfile />

This imports and uses the UserProfile component, which handles the loading, error, and success states.

✅ Result

Skeletons During Loading: Users will see animated placeholders (skeletons) instead of a blank screen or static “Loading…” text while the content is being fetched.
Smooth User Experience: The UI feels responsive even on slower networks because skeletons reassure users that the app is working behind the scenes.

✨ The Full Flow:

{#await} for handling simple async logic.
Functions for reloading or refreshing data.
Stores for centralizing and reusing data-fetching logic.
Promise.all for waiting on multiple async calls (e.g., loading user data and posts).
Skeletons for a polished loading state.

By combining these concepts, you can create an efficient, user-friendly, and responsive app that minimizes blank screens and unnecessary fetch requests.

Mini Project: Themed Todo Dashboard

Let’s bring it all together:

Theme via context (from Chunk 1).
Todos in a store.
User profile fetched async with skeletons.

📂 src/lib/todoStore.js

import { writable } from 'svelte/store';

export const todos = writable([
  { id: 1, text: 'Learn Svelte', done: true },
  { id: 2, text: 'Build something cool', done: false }
]);

📂 src/lib/TodoList.svelte

<script>
  import { todos } from '$lib/todoStore.js';
</script>

<h3>Todos</h3>
<ul>
  {#each $todos as todo}
    <li>
      <input type="checkbox" bind:checked={todo.done} />
      {todo.text}
    </li>
  {/each}
</ul>

<p>Completed: { $todos.filter(t => t.done).length } / { $todos.length }</p>

📂 src/lib/UserProfile.svelte (async, with skeletons)

<script>
  let promise = fetch('https://jsonplaceholder.typicode.com/users/1')
    .then(r => r.json());
</script>

{#await promise}
  <p>Loading user...</p>
{:then user}
  <h3>User: {user.name}</h3>
  <p>Email: {user.email}</p>
{/await}

📂 src/routes/+page.svelte

<script>
  import ThemeProvider from '$lib/ThemeProvider.svelte';
  import TodoList from '$lib/TodoList.svelte';
  import UserProfile from '$lib/UserProfile.svelte';
</script>

<ThemeProvider>
  <h1>Dashboard</h1>
  <UserProfile />
  <TodoList />
</ThemeProvider>

Boom 💥 You now have:

A themed dashboard (context).
Async user profile (await).
A reactive todo list (store + derived count).

Recap

We just covered:

{#await} for loading/error/success.
Refreshing async data.
Wrapping fetches in stores.
Combining async calls.
Skeletons for UX polish.
A mini dashboard combining context + async + stores.

At this point, you can handle real-world data flow in Svelte without breaking a sweat.

Next up: SvelteKit Routing & Layouts: Building Multi-Page Apps the Easy Way

A Beginner’s Guide to Svelte Stores (Writable, Readable, and Derived)

Ali Aslam — Mon, 08 Sep 2025 10:04:28 +0000

Imagine you build a counter button. Click it → the number goes up. Easy.

Then you add another button in a different part of the UI that’s supposed to control the same counter. You click one… it goes up. You click the other… nothing happens, because it’s got its own copy of the state.

This is like two people keeping score on different napkins. You write “5,” they write “3,” and now you’re arguing about who’s right.

What we need is a shared whiteboard 📝 — one place to keep the truth, so everyone’s on the same page.

That’s exactly what stores are in Svelte: a way to hold reactive values outside of any single component.

What is a store?

A store is just a special object that holds a value and notifies subscribers when it changes.

Any component can read from it.
Any component can write to it (if it’s writable).
And best of all, components update automatically when the store changes.

Think of it like a radio station 📻. The store broadcasts the current song (value), and every component listening gets the same tune instantly.

Creating your first writable store

The most common type of store is a writable store — one you can both read and update.

Let’s create one. We’ll keep our stores in a separate file so they’re easy to import anywhere.

📂 src/lib/stores.js

import { writable } from 'svelte/store';

// start our counter at 0
export const count = writable(0);

That’s it — we’ve got a store named count. Notice we export it so other files can import and use the same value.

Reading from the store

Let’s build a component that reads the store and shows the value.

📂 src/lib/CounterDisplay.svelte

<script>
  import { count } from './stores.js';
</script>

<p>The count is: {$count}</p>

That $count is Svelte’s auto-subscription syntax:

When this component mounts, it subscribes to count.
Whenever the value changes, the <p> updates automatically.
When the component unmounts, Svelte unsubscribes for us.

No boilerplate. No cleanup. Just $count.

To see it in action, let’s add this component to our page.

📂 src/routes/+page.svelte

<script>
  import CounterDisplay from '$lib/CounterDisplay.svelte';
</script>

<h1>Shared Counter Demo</h1>
<CounterDisplay />

Load the page and you’ll see: “The count is: 0”. (no increment button yet)

Updating the store

Of course, staring at 0 isn’t very exciting. Let’s add some controls to change the store’s value.

A writable store has two methods:

.set(newValue) → replace the value.
.update(fn) → calculate a new value based on the old one.

📂 src/lib/CounterControls.svelte

<script>
  import { count } from './stores.js';
</script>

<button onclick={() => count.update(n => n + 1)}>
  Increment
</button>

<button onclick={() => count.set(0)}>
  Reset
</button>

And use it in the page:

📂 src/routes/+page.svelte

<script>
  import CounterDisplay from '$lib/CounterDisplay.svelte';
  import CounterControls from '$lib/CounterControls.svelte';
</script>

<h1>Shared Counter Demo</h1>
<CounterDisplay />
<CounterControls />

Now you can increment and reset the count, and the display updates automatically. 🎉

The shorthand way

Since $count is reactive, you can also assign to it directly, just like a rune variable. Svelte turns $count = ... into a store update under the hood.

📂 src/lib/CounterControls.svelte

<script>
  import { count } from './stores.js';
</script>

<button onclick={() => $count++}>
  Increment
</button>

<button onclick={() => $count = 0}>
  Reset
</button>

When you do this, Svelte quietly updates the store behind the scenes. So even though $count looks like an ordinary variable, it’s really wiring into the store for you.

👉 Under the hood, these assignments get turned into calls to special methods like .set and .update. Don’t worry if that doesn’t make sense yet — we’ll dig into those methods in the next section. For now, just know that $count can be both a reader and a writer.

This shorthand is what you’ll see in most real projects because it keeps the code clean and natural. And since it’s all one shared store, your will instantly reflect the changes.

Multiple components, one store

The real superpower of stores is that many components can share them at once. Let’s make another button component that also increments the counter.

📂 src/lib/CounterButton.svelte

<script>
  import { count } from './stores.js';
</script>

<button onclick={() => $count++}>
  Add one (current: {$count})
</button>

Now drop it into the page along with the others:

📂 src/routes/+page.svelte

<script>
  import CounterDisplay from '$lib/CounterDisplay.svelte';
  import CounterControls from '$lib/CounterControls.svelte';
  import CounterButton from '$lib/CounterButton.svelte';
</script>

<h1>Shared Counter Demo</h1>
<CounterDisplay />
<CounterControls />
<CounterButton />

Click any of the buttons, and watch how the display and both buttons all stay perfectly in sync. That’s the shared whiteboard effect.

When should you use a store?

Quick rule of thumb:

Use $state for local state that only matters to one component.
Use a store when multiple components need to share the same truth.

Stores are your app’s bulletin board 📌. Post something once, and everyone can see the update.

Readable stores

Imagine a clock ⏰. Every second it ticks forward.
Do we really want every component to have the power to set the clock? No way. We only want them to read it.

That’s what readable stores are for: stores that provide values but don’t let consumers overwrite them.

📂 src/lib/time.js (note .js, not .svelte)

import { readable } from 'svelte/store';

// create a readable store that updates every second
export const time = readable(new Date(), (set) => {
  const interval = setInterval(() => {
    set(new Date());
  }, 1000);

  // cleanup when no one is using it
  return () => clearInterval(interval);
});

Let’s break this down:

We’re in a plain .js file, not .svelte, because this store doesn’t render anything. It’s just a little data factory that other components can import.
readable takes two arguments:

The initial value → here new Date().
A function that tells Svelte how to keep the store updated. It gets a special set callback we can call whenever we want to push a new value.
- Inside, we use setInterval to call set(new Date()) every second. That keeps the store ticking.
- Finally, we return a cleanup function. This is important: if no component is subscribed anymore, Svelte calls this function to free resources. In this case, it clears the interval so we don’t waste memory or battery.

So time is a read-only stream of values: components can subscribe to it, but they can’t assign to it or call .set themselves.

Now let’s use it.

📂 src/lib/Clock.svelte

<script>
  import { time } from './time.js';
</script>

<p>The time is: {$time.toLocaleTimeString()}</p>

📂 src/routes/+page.svelte

<script>
  import Clock from '$lib/Clock.svelte';
</script>

<h1>Shared Clock Demo</h1>
<Clock />

Now your page shows a live clock along with the counter. The Clock can read time, but it can’t mess with it. Perfect.

Derived stores

What if we want a value that’s calculated from one or more stores? Enter derived stores.

Think about a shopping cart 🛒. You’ve got an array of items, each with a price. You also want to display the total cost. The total depends on the items, so instead of recalculating manually everywhere, let’s make a derived store.

📂 src/lib/cart.js

import { writable, derived } from 'svelte/store';

// array of items in the cart
export const cart = writable([
  { name: 'Apples', price: 2 },
  { name: 'Bananas', price: 3 }
]);

// derived store: sum of item prices
export const total = derived(cart, ($cart) =>
  $cart.reduce((sum, item) => sum + item.price, 0)
);

Here’s what’s happening:

cart is our base store, holding an array of items.
total is a derived store.
- It takes cart as input.
- The arrow function ( $cart ) => … runs whenever cart changes.
- Here, .reduce is a regular JavaScript array method (not part of Svelte) that adds up all the item prices into one number. Here, it walks through every item in the array and keeps a running total of the price values. We start from 0 and add each item’s price one by one.
- Whatever that function returns becomes the new value of total.

So total is always kept up to date — if the cart changes, the total recalculates automatically.

Now let’s display it:
📂 src/lib/CartSummary.svelte

<script>
  import { cart, total } from './cart.js';
</script>

<h2>Cart</h2>
<ul>
  {#each $cart as item}
    <li>{item.name} — ${item.price}</li>
  {/each}
</ul>

<p>Total: ${$total}</p>

📂 src/routes/+page.svelte

<script>
  import CartSummary from '$lib/CartSummary.svelte';
</script>

<CartSummary />

Now your UI shows a live-updating cart total, automatically recalculated whenever cart changes.

💡 Mini challenge: try adding a way to change quantities or add new items to the cart, and watch how the total store updates all by itself.

Stores vs Props

At this point you might be thinking: “Why not just pass values down as props?” Good question.

Here’s the rule of thumb:

Props are perfect when you pass data from a parent to its direct children.
Stores are better when many components across your app need to share the same state, especially if they’re not directly related in the tree.

In other words: Use props until it hurts. When it does, reach for a store.

Props are like handing notes directly to your kids. Stores are like putting it on the family fridge where everyone in the house can see.

Mini Project — A Todo App with Stores

Instead of throwing together a bunch of unrelated demos, let’s build one cohesive little app: a Todo List.

This will showcase everything we’ve learned so far:

A writable store to hold the todos.
A derived store to calculate how many are completed.
A readable store for static app info like version number.

Step 1: Define our stores

📂 src/lib/todos.js

import { writable, derived, readable } from 'svelte/store';

// writable: our list of todos
export const todos = writable([
  { text: 'Learn stores', done: true },
  { text: 'Build a Svelte app', done: false }
]);

// derived: count how many are done
export const completedCount = derived(todos, ($todos) =>
  $todos.filter(todo => todo.done).length
);

// readable: static app info
export const appVersion = readable('v1.0.0');

What’s going on here?

todos is a writable store. Any component can both read ($todos) and update it.
completedCount is a derived store. It watches todos and automatically recalculates whenever the todos change.
appVersion is a readable store. It’s just a constant value that can’t be overwritten from outside.

Step 2: A component to manage todos

📂 src/lib/TodoList.svelte

<script>
  import { todos } from './todos.js';

  let newTodo = '';

  function addTodo() {
    if (newTodo.trim()) {
      $todos = [...$todos, { text: newTodo, done: false }];
      newTodo = '';
    }
  }

  function toggleTodo(index) {
    $todos = $todos.map((todo, i) =>
      i === index ? { ...todo, done: !todo.done } : todo
    );
  }
</script>

<h2>Todos</h2>

<input bind:value={newTodo} placeholder="New todo" />
<button onclick={addTodo}>Add</button>

<ul>
  {#each $todos as todo, i}
    <li>
      <label>
        <input type="checkbox" checked={todo.done} onclick={() => toggleTodo(i)} />
        {todo.text}
      </label>
    </li>
  {/each}
</ul>

Breakdown:

We import the todos store.
newTodo is just local state for the input box.
addTodo() uses $todos = ... shorthand to add a new item.
toggleTodo() flips the done status of a todo at a given index.
The <ul> shows every todo, with checkboxes that stay in sync thanks to the store.

Every time we change $todos, any component using it updates automatically.

Step 3: A component to show summary info

📂 src/lib/TodoSummary.svelte

<script>
  import { todos, completedCount, appVersion } from './todos.js';
</script>

<p>
  Completed: {$completedCount} / {$todos.length}
</p>

<p>
  App version: {$appVersion}
</p>

Breakdown:

$completedCount updates whenever todos changes — no manual math.
$todos.length shows the total number of tasks.
$appVersion comes from our readable store. Nothing can overwrite it, so it’s guaranteed to stay consistent.

Step 4: Bring it together

📂 src/routes/+page.svelte

<script>
  import TodoList from '$lib/TodoList.svelte';
  import TodoSummary from '$lib/TodoSummary.svelte';
</script>

<h1>Todo App with Stores</h1>
<TodoList />
<TodoSummary />

Now we’ve got a full mini app:

Add todos.
Toggle them complete/incomplete.
Watch the completed count update instantly.
See a static app version displayed at the bottom.

Why this is powerful

This tiny Todo app shows all three store types working together in a realistic scenario:

The todos are shared state (multiple components read/write them).
The completed count is derived automatically.
The app version is read-only.

This is exactly how you’d structure state in a real-world app: writable for user data, derived for computed values, and readable for constants.

Recap

In this article we’ve gone far beyond local state:

Writable stores → values you can read and update from anywhere.
Readable stores → values that components can only listen to, not change.
Derived stores → computed values that update automatically when dependencies change.
When to use stores vs props → props for local communication, stores for global/shared truths.
A full mini project combining them.

Stores are the glue that keeps state consistent across your Svelte app.

Next up, we’ll look at context — another way to share data, but in a more scoped way — and then we’ll bring in async data fetching. That’s where things start feeling like a real-world app.

Next article: Mastering Context and Async Data in Svelte (with Examples)

Tailwind CSS + Svelte: Utility-First Styling at Scale

Ali Aslam — Sun, 07 Sep 2025 08:20:27 +0000

Svelte’s scoped CSS is fantastic for encapsulated components. But when your app grows, writing custom CSS for every button, card, and margin tweak can slow you down.

That’s where Tailwind CSS shines. It’s a utility-first framework that gives you ready-to-use classes for spacing, typography, colors, and dark mode — all inline in your markup. Combine it with Svelte’s scoped CSS, and you get the best of both worlds: rapid prototyping + maintainable components.

In this final part, you’ll learn how to:

Set up Tailwind in SvelteKit.

Style components with Tailwind utilities.

Implement dark mode with one class toggle.

Mix Tailwind utilities with scoped CSS.

Avoid pitfalls like “class soup.”

We’ll end with a styled mini-project that combines everything.

Step 12: Tailwind + Svelte — A Match Made in Heaven 💘

By now, you’ve seen how powerful Svelte’s built-in styling is. Scoped CSS, :global, and class directives cover a lot of ground.

But sometimes you don’t want to write a custom CSS rule for every little thing:

Spacing (margin, padding)
Colors and backgrounds
Rounded corners, shadows, hover effects

That’s where Tailwind CSS shines. It’s a utility-first CSS framework that gives you ready-made classes like:

p-4 → padding
bg-blue-500 → background color
rounded-lg → rounded corners

Instead of switching back and forth between HTML and CSS files, you style inline with classes right in your Svelte markup.

Before (manual CSS)

<!-- Button.svelte -->
<button class="btn">Click Me</button>

<style>
  .btn {
    background: royalblue;
    color: white;
    padding: 0.5rem 1rem;
    border-radius: 0.5rem;
    cursor: pointer;
  }
</style>

After (Tailwind)

<!-- Button.svelte -->
<button class="bg-blue-500 text-white px-4 py-2 rounded-lg">
  Click Me
</button>

No <style> block needed — Tailwind handles it all with utilities.

👉 The point isn’t to abandon Svelte’s styling — it’s that Tailwind makes common patterns faster and more consistent, while Svelte’s scoped CSS is still great for one-off component styles.

Step 13: Setting Up Tailwind in SvelteKit

Tailwind integrates seamlessly with SvelteKit. Let’s walk through it step by step.

1. Install Tailwind and friends

In your project root, run:

npm install -D tailwindcss postcss autoprefixer
npx tailwindcss init tailwind.config.cjs -p

That generates two files:

tailwind.config.cjs → Tailwind config
postcss.config.cjs → PostCSS config

2. Configure Tailwind

Open tailwind.config.cjs and make sure it scans your .svelte files:

// tailwind.config.cjs
module.exports = {
  content: ['./src/**/*.{html,js,svelte,ts}'],
  theme: {
    extend: {}
  },
  plugins: []
};

This tells Tailwind to purge unused CSS from all your Svelte components.

3. Add Tailwind to your global CSS

Create (or edit) src/app.css and add the Tailwind layers:

@tailwind base;
@tailwind components;
@tailwind utilities;

4. Import CSS into your root layout

In SvelteKit, the root layout is src/routes/+layout.svelte. Import app.css there:

<script>
  import "../app.css";
</script>

<slot />

This ensures Tailwind styles are available everywhere in your app.

✅ That’s it! Now you can start using Tailwind classes directly in any .svelte file.

Example:

<button class="bg-blue-500 hover:bg-blue-600 text-white px-4 py-2 rounded-lg">
  Click Me
</button>

Step 14: Using Tailwind in Components

Now that Tailwind is set up, let’s use it inside a Svelte component.
You don’t need a <style> block here — just apply Tailwind classes directly in the class attribute.

Button.svelte

<script>
  export let label = "Click Me";
</script>

<button class="bg-blue-500 hover:bg-blue-600 text-white px-4 py-2 rounded-lg">
  {label}
</button>

Then import it into a page (e.g. src/routes/+page.svelte):

<script>
  import Button from '$lib/Button.svelte';
</script>

<h1>Welcome</h1>
<Button label="Get Started" />

✅ This instantly gives you a nicely styled button with:

Blue background (bg-blue-500)
Hover state (hover:bg-blue-600)
White text, padding, and rounded corners

No extra CSS needed.

⚡ This workflow is fantastic for prototyping or for teams that want consistent, production-ready styles without writing lots of custom CSS.

Step 15: Dark Mode with Tailwind

Remember theming from Step 10? Tailwind makes dark mode ridiculously easy.

First, enable it in tailwind.config.cjs:

module.exports = {
  darkMode: 'class', // or 'media'
  content: ['./src/**/*.{html,js,svelte,ts}'],
  theme: { extend: {} }
};

Now you can use the dark: prefix to define alternate styles.

DarkModeDemo.svelte

<script>
  let dark = false;

  function toggleTheme() {
    dark = !dark;
    document.body.classList.toggle("dark", dark);
  }
</script>

<button
  class="px-4 py-2 mb-4 bg-gray-200 dark:bg-gray-700 rounded-lg"
  on:click={toggleTheme}
>
  Toggle Dark Mode
</button>

<div class="p-4 bg-white text-black dark:bg-black dark:text-white rounded-lg">
  Hello Dark Mode 👋
</div>

Usage: import DarkModeDemo into a page (+page.svelte) and try toggling.

✅ With just the dark: prefix:

Background and text colors flip instantly
Works across the whole app if you apply dark to body

👉 Tailwind basically turns dark mode into a one-liner, compared to manually managing CSS variables.

Step 16: Mixing Tailwind with Scoped CSS

Tailwind is amazing for layout, spacing, and colors — but sometimes you need that extra polish (like smooth transitions, keyframes, or fine-grained overrides). That’s where Svelte’s scoped CSS still shines.

The best practice is:
👉 Use Tailwind for 90% of styles.
👉 Add scoped CSS when utilities can’t express what you need.

Example: Combining Both

ActiveButton.svelte

<script>
  export let active = false;

  function toggle() {
    active = !active;
  }
</script>

<button
  class="px-4 py-2 rounded-lg text-white"
  class:bg-blue-500={active}
  class:bg-gray-400={!active}
  on:click={toggle}
>
  {active ? "Active" : "Inactive"}
</button>

<style>
  /* Scoped CSS adds a smooth background transition */
  button {
    transition: background 0.3s ease;
  }
</style>

Usage in a page:

<script>
  import ActiveButton from '$lib/ActiveButton.svelte';
</script>

<ActiveButton />

Now when you click the button:

Tailwind sets up the base look (px-4, rounded-lg, colors).
Svelte’s scoped CSS makes the color fade smoothly instead of snapping.

This demonstrates the sweet spot: Tailwind gives you productivity, scoped CSS gives you control.

Step 17: Tailwind Gotchas ⚠️

Tailwind and Svelte work beautifully together, but here are a few pitfalls to watch for:

Class soup (too many utilities in one element) Tailwind encourages stacking small classes, but it can get unreadable:

   <div class="flex items-center justify-between px-4 py-2 bg-blue-500 rounded-lg shadow-md hover:bg-blue-600 text-white">
     Header
   </div>

✅ Fix: Extract into a component (e.g. <Header />) or use Tailwind’s @apply in a global stylesheet to bundle common combos.

Purging unused classes Tailwind removes unused CSS at build time. If your tailwind.config.cjs doesn’t include *.svelte, your styles may vanish in production.

Example config:

   module.exports = {
     content: ['./src/**/*.{html,js,svelte,ts}'], // ✅ includes .svelte
     theme: { extend: {} },
     plugins: []
   }

Scoped CSS vs Tailwind utilities Tailwind classes are global, while Svelte styles are scoped. Luckily, they don’t usually clash — but remember:

   <div class="bg-blue-500">Hello</div>

   <style>
     div { background: red; } /* scoped → applies only here */
   </style>

✅ Solution: Use Tailwind for general styles, scoped CSS only for fine-tuning this component.

👉 Rule of thumb: Use Tailwind for speed, scoped CSS for precision.

Step 18: Mini-Project — Colorful Card Grid 🃏

Let’s put everything together — scoped styles, Tailwind utilities, dark mode, and dynamic classes — to make a mini card grid.

1. Create a `Card.svelte` component

src/lib/Card.svelte

<script>
  export let title;
  export let content;
  export let color = "blue"; // accepts "blue" | "green" | "purple"

  // Map colors to real Tailwind classes (important!)
  const colorClasses = {
    blue: "bg-blue-100 border-blue-500 text-blue-800",
    green: "bg-green-100 border-green-500 text-green-800",
    purple: "bg-purple-100 border-purple-500 text-purple-800"
  };
</script>

<div
  class={`p-6 rounded-xl shadow-lg transition border-l-4 ${colorClasses[color]}`}
>
  <h2 class="text-xl font-bold mb-2">{title}</h2>
  <p>{content}</p>
</div>

2. Use it in the main page

src/routes/+page.svelte

<script>
  import Card from "$lib/Card.svelte";
</script>

<div class="min-h-screen bg-gradient-to-r from-pink-200 via-purple-200 to-indigo-200 p-10">
  <h1 class="text-3xl font-bold mb-6 text-center text-indigo-700">
    Colorful Cards Demo
  </h1>

  <div class="grid gap-6 grid-cols-1 sm:grid-cols-2 lg:grid-cols-3">
    <Card
      title="Learn Svelte"
      content="Build fast, reactive UIs."
      color="blue"
    />
    <Card
      title="Style with Tailwind"
      content="Utility-first classes keep CSS tidy."
      color="green"
    />
    <Card
      title="Compose Components"
      content="Cards, buttons, modals — all reusable."
      color="purple"
    />
  </div>
</div>

3. What this shows

✅ Tailwind utilities → spacing, shadows, gradients, responsive grid.
✅ Dynamic classes → different colors per card.
✅ Scoped CSS (optional) → if you want to add small tweaks.
✅ Dark mode ready → you can extend Card.svelte with dark: variants.

Result: A beautiful, colorful grid of cards instead of a plain page.

👉 This is a complete, working mini-project. Run your SvelteKit dev server, and you’ll see a gradient background + three colorful cards. 🎨

Wrapping Up

In this article, you learned how to style Svelte apps like a pro:

Theming with CSS variables and Tailwind dark mode.
Combining Tailwind with Svelte for maximum productivity.

You’ve now seen how Tailwind and Svelte complement each other — scoped CSS for fine control, utilities for rapid styling, and dark mode baked in. With these tools, you can build apps that are not only reactive but also beautifully styled and consistent at scale.

👉 That wraps up our styling series. Next, we’ll move on to state & data flow in Svelte: stores, context API, and advanced reactivity patterns.

👉 Next up: A Beginner’s Guide to Svelte Stores (Writable, Readable, and Derived).
That’s where we’ll go beyond props and events into app-wide state management.

Svelte Motion & Theming Guide: Transitions, Animations, and Dark Mode Explained

Ali Aslam — Sun, 07 Sep 2025 08:18:12 +0000

A static UI works. A delightful UI moves. Animation and theming are what give apps personality — the fade-in of a modal, the spring of a draggable element, the instant mood switch from light to dark mode.

Svelte makes this surprisingly easy with built-in transitions, motion utilities, and flexible theming strategies. No external animation library required.

In this article, you’ll learn how to:

Add transitions like fade, fly, and scale.
Animate lists when items move with animate:flip.
Use motion stores (tweened, spring) for reactive animations.
Build theming systems with CSS variables or props.

By the end, you’ll have the tools to make your UI not just functional, but alive.

Making Components Come Alive with Transitions ✨

A static UI is fine… but a delightful UI breathes. Svelte makes it almost too easy to add motion with the transition: directive.

Example: Fade Transition

src/lib/FadeDemo.svelte

<script>
  // Import one of Svelte's built-in transitions
  import { fade } from 'svelte/transition';

  // Controls whether the box is visible
  let visible = true;
</script>

<!-- Button toggles the state -->
<button on:click={() => visible = !visible}>
  Toggle Box
</button>

<!-- 
  - The {#if} block ensures the <div> is actually added/removed from the DOM
  - transition:fade makes it fade in/out when that happens
-->
{#if visible}
  <div transition:fade>✨ Hello World</div>
{/if}

Using the Component

src/routes/+page.svelte

<script>
  import FadeDemo from '$lib/FadeDemo.svelte';
</script>

<h1>Transitions Demo</h1>
<FadeDemo />

What’s Happening

When visible is true, Svelte creates the <div> and mounts it into the DOM.

Because we used transition:fade, it fades in smoothly.

When visible becomes false, Svelte runs the fade-out animation before removing the element from the DOM.
The {#if} block is essential:

If you just hid the <div> with CSS (display: none), there would be no mount/unmount → no transition.

All of this happens with zero manual CSS keyframes or JavaScript timers.

✅ That’s literally one line (transition:fade) to get buttery-smooth animations.

Customizing Transitions ✨

Svelte ships with several built-in transitions: fade, fly, slide, scale, and blur.
Each of them accepts optional parameters like duration, delay, or effect-specific settings.

Example: Different Transitions

src/lib/TransitionsDemo.svelte

<script>
  import { fade, fly, scale } from 'svelte/transition';

  let show = true;
</script>

<button on:click={() => show = !show}>
  Toggle Elements
</button>

{#if show}
  <div transition:fade={{ duration: 2000 }}>
    🌙 Slow Fade (2s)
  </div>

  <div transition:fly={{ y: 100, duration: 700 }}>
    🚀 Fly in from below
  </div>

  <div transition:scale={{ start: 0.5, duration: 600 }}>
    🔍 Scaling in
  </div>
{/if}

Using It in the Page

src/routes/+page.svelte

<script>
  import TransitionsDemo from '$lib/TransitionsDemo.svelte';
</script>

<h1>Transitions Demo</h1>
<TransitionsDemo />

How It Works

fade={{ duration: 2000 }} → element fades in/out over 2 seconds.
fly={{ y: 100, duration: 700 }} → element starts 100px lower and flies upward into place over half a second.
scale={{ start: 0.5 }} → element begins at 50% size and scales up to full size.

👉 You can combine transitions with conditional rendering ({#if}) to animate elements as they enter or leave the DOM.

Animate Lists with `animate:flip`

Lists often need animations when items are added, removed, or reordered. Without animation, the DOM just snaps into place — but with animate:flip, Svelte smoothly transitions items from their old position to their new position.

FLIP stands for:

First → record the element’s initial position.
Last → record its final position after state changes.
Invert → figure out the delta between them.
Play → animate between the two.

Example: Animated List

src/lib/AnimatedList.svelte

<script>
  import { flip } from 'svelte/animate';

  let items = [1, 2, 3, 4, 5];

  function shuffle() {
    // Shuffle the array randomly
    items = [...items].sort(() => Math.random() - 0.5);
  }
</script>

<button on:click={shuffle}>Shuffle</button>

<ul>
  {#each items as item (item)}
    <!-- (item) makes it a keyed list -->
    <li animate:flip>{item}</li>
  {/each}
</ul>

<style>
  ul {
    display: flex;
    gap: 1rem;
    list-style: none;
    padding: 0;
  }

  li {
    background: lightblue;
    padding: 1rem;
    border-radius: 6px;
    min-width: 40px;
    text-align: center;
  }
</style>

Using It

src/routes/+page.svelte

<script>
  import AnimatedList from '$lib/AnimatedList.svelte';
</script>

<h1>Animated List Demo</h1>
<AnimatedList />

Why It Works

{#each items as item (item)} → makes it a keyed list using the item value as the key.
animate:flip → tells Svelte: “when items move, animate from their old position to their new one.”
When you press Shuffle, Svelte compares before/after positions and smoothly animates the changes.

👉 Without (item) as the key, Svelte might just reuse DOM nodes, and the animation wouldn’t behave as expected.

Motion Utilities — `tweened` and `spring`

Not all motion is about elements entering and leaving the DOM. Sometimes you want the values themselves to animate smoothly — numbers ticking up, positions gliding across the screen, sliders snapping into place.

Svelte ships two special reactive stores for this:

tweened → animates values linearly or with easing.
spring → animates values with a natural spring-like effect.

Example 1: Tweened Store (Smooth Number Counting)

src/lib/TweenedCounter.svelte

<script>
  import { tweened } from 'svelte/motion';
  import { cubicOut } from 'svelte/easing';

  // Create a tweened store with starting value 0
  let count = tweened(0, { duration: 400, easing: cubicOut });

  function increment() {
    // .set() updates the store
    // $count is the "auto-subscription" value of the store
    count.set($count + 10);
  }
</script>

<button on:click={increment}>Add 10</button>
<p>Current count: {$count.toFixed(0)}</p>

👉 The magic here is $count: whenever you prefix a store with $, Svelte auto-subscribes to it and gives you its current value. When you call count.set(...), it doesn’t just jump — it smoothly animates toward the new value.

Example 2: Spring Store (Smooth Position Animation)

src/lib/SpringBall.svelte

<script>
  import { spring } from 'svelte/motion';

  // Create a spring store with an object value
  let pos = spring({ x: 0, y: 0 });

  function moveRight() {
    pos.update(p => ({ ...p, x: p.x + 100 }));
  }
</script>

<button on:click={moveRight}>Move Right</button>

<div class="ball" style="transform: translate({$pos.x}px, {$pos.y}px)">
  🟢
</div>

<style>
  .ball {
    position: relative;
    display: inline-block;
    margin-top: 1rem;
    font-size: 2rem;
    transition: transform 0.1s linear;
  }
</style>

Now when you click the button, the green dot slides right — not instantly, but with a springy “bounce.”

This feels more natural than a plain tween and is great for draggable UIs, sliders, or playful micro-interactions.

Using Them in Your Page

src/routes/+page.svelte

<script>
  import TweenedCounter from '$lib/TweenedCounter.svelte';
  import SpringBall from '$lib/SpringBall.svelte';
</script>

<h1>Motion Demos</h1>
<TweenedCounter />
<SpringBall />

Theming Strategies

Sooner or later, every app needs theming: light/dark mode, brand palettes, or even seasonal tweaks like “holiday colors.” In Svelte you have multiple ways to achieve this — let’s look at the most common.

Option 1: CSS Variables (Global Theme)

Use CSS custom properties to define colors at the root level. Toggle a class on <body> (or <html>) to switch themes.

src/routes/+page.svelte

<script>
  function toggleTheme() {
    document.body.classList.toggle("dark");
  }
</script>

<button on:click={toggleTheme}>Toggle Theme</button>

<div class="box">Hello Theming</div>

<style>
  /* Define light theme variables on :root */
  :global(:root) {
    --bg: white;
    --text: black;
  }

  /* Override them when .dark is present */
  :global(.dark) {
    --bg: black;
    --text: white;
  }

  .box {
    background: var(--bg);
    color: var(--text);
    padding: 1rem;
    border-radius: 6px;
  }
</style>

✅ Works app-wide, good for shared themes.

Option 2: Prop-Driven Themes (Per Component)

Sometimes you want a component to be themed independently of the global setting. In that case, pass a theme prop.

src/lib/ThemedBox.svelte

<script>
  export let theme = "light"; // "light" | "dark"
</script>

<div class:dark={theme === "dark"} class="box">
  Themed Component ({theme})
</div>

<style>
  .box {
    padding: 1rem;
    border-radius: 6px;
  }
  .dark {
    background: black;
    color: white;
  }
  :global(.box):not(.dark) {
    background: white;
    color: black;
  }
</style>

Usage in src/routes/+page.svelte

<script>
  import ThemedBox from '$lib/ThemedBox.svelte';
</script>

<ThemedBox theme="light" />
<ThemedBox theme="dark" />

✅ Good for isolated widgets where theme varies per instance.

Option 3: Tailwind for Theming (Utility-First)

Tailwind makes theming effortless with its dark: variant.

src/routes/+page.svelte

<script>
  function toggleTheme() {
    document.body.classList.toggle("dark");
  }
</script>

<button on:click={toggleTheme}>Toggle Theme</button>

<div class="p-4 rounded-lg bg-white text-black dark:bg-black dark:text-white">
  Hello Tailwind Dark Mode
</div>

Common Gotchas ⚠️

Even though Svelte’s styling and motion features are powerful, there are a few traps you’ll want to avoid:

1. Transitions only work when elements enter/leave the DOM

This won’t work (no transition):

<!-- ❌ Just hiding with CSS -->
<div style="display: {visible ? 'block' : 'none'}" transition:fade>
  I won’t fade properly
</div>

Why? The <div> never actually leaves the DOM — it’s just hidden.

✅ Correct way:

{#if visible}
  <div transition:fade>I fade in and out!</div>
{/if}

2. Always key your lists when animating with `flip`

Without keys:

<ul>
  {#each items as item}
    <li animate:flip>{item}</li>
  {/each}
</ul>

❌ Items can jump or morph strangely if order changes.

✅ With keys:

<ul>
  {#each items as item (item)}
    <li animate:flip>{item}</li>
  {/each}
</ul>

Now Svelte knows exactly which element corresponds to which item.

3. Don’t mix too many motion types

It’s tempting to pile on transitions and animations:

<div transition:fade transition:scale animate:flip>
  Chaos 😵
</div>

While Svelte lets you do this, the result is often distracting.

👉 Rule of thumb: pick one or two complementary effects (like fade + slide), and keep it purposeful.

Quick Recap

In this chunk, you learned how to:

Use Svelte’s built-in transition: directive.
Animate reordering with animate:flip.
Use motion stores (tweened and spring).
Implement theming via CSS variables or props.

You now know how to bring your Svelte components to life — with smooth transitions, animated lists, reactive motion stores, and multiple theming strategies. These techniques add polish and personality to your apps without unnecessary complexity.

👉 In the final article of this series, we’ll bring in Tailwind CSS — combining Svelte’s scoped styles with utility-first classes for maximum productivity and design consistency.

Next article: Tailwind + Svelte (Utility-First Styling at Scale)

Styling in Svelte (Scoped CSS, :global, and Class Directives)

Ali Aslam — Sun, 07 Sep 2025 07:58:25 +0000

Why Styling Matters 🎨

Code makes apps work, but styling makes them delightful.
Imagine a to-do app that functions perfectly — but everything is plain Times New Roman, unstyled checkboxes, and buttons straight out of 1995. It works… but no one wants to use it.

That’s where styling comes in. A clean, well-designed UI makes your app feel modern, usable, and trustworthy.

Svelte doesn’t just give you reactive components — it also gives you a built-in styling model. Unlike React (where you often reach for extras like CSS Modules or styled-components), Svelte treats styles as a first-class citizen, right inside your .svelte files.

👉 By the end of this guide, you’ll be able to:

Write scoped CSS that applies only to one component.
Escape the scope with :global when needed.
Use class directives for dynamic, reactive styling.
Supercharge your workflow with Tailwind CSS utilities.

Let’s begin with the foundation: scoped styles — Svelte’s secret to avoiding CSS spaghetti.

Step 1: Scoped CSS — The Svelte Way

Every Svelte component (.svelte file) can contain a <style> block.
The key difference from plain HTML/CSS:

In regular HTML, a <style> tag applies globally across the whole page.
In Svelte, a <style> tag inside a component is scoped: it only affects the markup in that same file.

This is what makes component-based styling safe and predictable.

Example: A Styled Button

src/lib/Button.svelte

<script>
  // This is a reusable button component.
  // "label" is a prop passed in by the parent.
  export let label = "Click me";
</script>

<!-- The markup that will be styled -->
<button>{label}</button>

<!-- 
  🔽 This style tag belongs to *this component only*. 
  It won’t leak to other <button> elements elsewhere in your app.
-->
<style>
  button {
    background: royalblue;
    color: white;
    border: none;
    padding: 0.5rem 1rem;
    border-radius: 6px;
    cursor: pointer;
  }
</style>

Using the Component

src/routes/+page.svelte

<script>
  import Button from '$lib/Button.svelte';
</script>

<h1>Scoped CSS Demo</h1>

<!-- Two buttons, styled identically -->
<Button label="Save" />
<Button label="Cancel" />

<!-- A plain HTML button (not styled by Button.svelte) -->
<button>Plain Button</button>

✅ The <Button /> components have the royal blue styling.
✅ The plain <button> at the bottom looks unstyled — proving styles don’t leak out.
✅ You don’t need unique class names like .button-primary or .button-danger to avoid conflicts — scoping is automatic.

Step 2: How Scope Actually Works

So how does Svelte keep your styles from leaking out?

Behind the scenes, the compiler rewrites your CSS selectors to be unique per component.

Example: Your Code

If you write this in Button.svelte:

button {
  background: royalblue;
}

What Svelte Compiles To

Svelte generates a random hash (like svelte-xyz123) and rewrites your code:

button.svelte-xyz123 {
  background: royalblue;
}

And the <button> element in the DOM gets:

<button class="svelte-xyz123">Save</button>

✅ Result: the style applies only to buttons in this component.
❌ Other <button>s elsewhere in your app aren’t affected.

You don’t need to worry about those svelte-xyz123 classes — Svelte manages them automatically. But knowing this explains why scoped CSS “just works.”

👉 This is why Svelte projects don’t descend into CSS spaghetti, where one stylesheet accidentally overrides another.

Step 3: Escaping Scope with `:global`

By default, styles inside a component are scoped — they only apply locally.
But sometimes, you really do need styles that affect the entire app:

A CSS reset (removing browser defaults).
Global typography (setting fonts and line-heights).
Theming (e.g. dark mode background).

That’s where :global comes in.

Example: A Global Reset

src/routes/+layout.svelte

<style>
  /* This targets the <body> across the whole app */
  :global(body) {
    margin: 0;
    font-family: system-ui, sans-serif;
    background: #fafafa;
  }
</style>

<slot />

Now every page in your app inherits these global styles.

Example: Mixing Scoped and Global

You can also combine scoped selectors with global ones:

<style>
  /* Only <span> inside this component’s <button> are styled */
  button :global(span) {
    color: yellow;
  }
</style>

<button>
  Normal <span>highlighted</span> text
</button>

Here, the <button> remains scoped, but the span inside it is styled using a global selector.

⚠️ Rule of thumb:
Stay scoped by default (safer, predictable).
Use :global only for resets, shared typography, or app-wide theming.

Step 4: Dynamic Classes with `class:` Directive

Static styles are nice, but real UIs are dynamic.
Think about:

A “selected” button in a toolbar.
An “active” tab in navigation.
A form field that turns red when invalid.

You don’t want to hard-code these classes — you want them to respond to state.

Example: Toggling an Active Class

src/lib/ToggleButton.svelte

<script>
  let active = false; // local state
</script>

<!-- 
  class:active={active} means:
  → add the class "active" when active === true
  → remove it when active === false
-->
<button
  class:active={active}
  on:click={() => active = !active}
>
  {active ? "Active" : "Inactive"}
</button>

<style>
  /* Normal style */
  button {
    padding: 0.5rem 1rem;
    border: none;
    cursor: pointer;
  }

  /* Extra style when active */
  .active {
    background: green;
    color: white;
  }
</style>

✅ Now when you click the button, the active class toggles on and off automatically.
❌ Without class:, you’d have to write something messy like:

<button class={active ? "active" : ""}>...</button>

Svelte’s class: directive keeps it clean, reactive, and declarative.

Step 5: Multiple Class Directives

Sometimes a component can have different visual variants.
Think of buttons: primary, danger, success, outline… you don’t want to make a new component for each.

With Svelte, you can stack multiple class: directives to toggle different classes based on state or props.

Example: Button Variants

src/lib/VariantButton.svelte

<script>
  // Svelte 5 runes props
  let { type = "primary" } = $props(); // "primary" | "danger" | "success"
</script>

<button
  type="button"
  class:primary={type === "primary"}
  class:danger={type === "danger"}
  class:success={type === "success"}
>
  {type === "primary" ? "Save" : type === "danger" ? "Delete" : "OK"}
</button>

<style>
  button {
    padding: 0.5rem 1rem;
    border: none;
    border-radius: 4px;
    cursor: pointer;
    color: white;
  }

  .primary {
    background: royalblue;
  }

  .danger {
    background: crimson;
  }

  .success {
    background: seagreen;
  }
</style>

Usage

<script>
  import VariantButton from '$lib/VariantButton.svelte';
</script>

<VariantButton type="primary" />
<VariantButton type="danger" />
<VariantButton type="success" />

✅ The button automatically switches between green blue and red depending on the type.
✅ You can add as many variants as you want (success, warning, etc).
❌ Without class directives, you’d need to manually concatenate classes, which quickly gets messy.

Step 6: Inline Styles

Most of the time you’ll use CSS classes for styling, but sometimes you need a quick dynamic style — like controlling the exact width, height, or color of an element from a variable.

Svelte lets you bind styles directly inside the style attribute.

Example: Dynamic Box

src/lib/DynamicBox.svelte

<script>
<script>
  // Reactive variable that controls size
  let size = $state(50);
</script>

<div
  style="width: {size}px; height: {size}px; background: coral;"
></div>

<button type="button" onclick={() => size += 20}>
  Grow Box
</button>

✅ The box grows every time you click the button.
✅ Inline styles are fully reactive — any change to size updates the DOM instantly.

⚠️ Best practice:
Use inline styles only for one-off, highly dynamic values (like size, position, or transform).
For reusable styles (colors, padding, hover states), stick to CSS classes, which are easier to maintain and theme.

Quick Recap

So far, you’ve learned:

Svelte styles are scoped by default.
:global lets you escape scope for resets or shared rules.
class: directives toggle classes reactively.
Inline styles work for dynamic values.

You’ve now mastered the foundation of Svelte styling: scoped CSS, global overrides, class toggling, and inline styles. With these tools, you can already build clean, reusable components that look and behave consistently.

👉 In the next article, we’ll take things further with motion and theming - transitions, animations, and strategies for handling light/dark modes.

Loops in Svelte — {#each}, Keys, and Building a Todo App

Ali Aslam — Sun, 07 Sep 2025 05:48:25 +0000

Quick question: when was the last time you saw an app that only showed one thing?

One todo in your todo app.
One email in your inbox.
One meme in your feed.

That would be… the saddest app ever. 😂

Real apps deal with lists. Dozens, hundreds, sometimes thousands of things. And we don’t want to copy-paste the same <div> a hundred times — we want the computer to do the boring work for us.

That’s where Svelte loops come in. They’re like a copy machine 📠: you design one template, then Svelte stamps out as many copies as you need.

In this chapter, we’ll learn how to:

Repeat elements with {#each}.
Pull out properties cleanly with destructuring.
Use indices when you need “first, second, third.”
Handle empty arrays gracefully.
Nest loops for categories and sub-items.

By the end, you’ll be ready to render everything from a tiny todo list ✅ to a giant shopping cart 🛒 — all without breaking a sweat.

The `{#each}` Block

The simplest loop in Svelte is {#each}. Let’s render a list of fruits.

📂 src/lib/FruitList.svelte

<script>
  let fruits = $state(['Apple', 'Banana', 'Cherry']);
</script>

<ul>
  {#each fruits as fruit}
    <li>{fruit}</li>
  {/each}
</ul>

📂 src/routes/+page.svelte

<script>
  import FruitList from '$lib/FruitList.svelte';
</script>

<FruitList />

Breaking it down 🍌

let fruits = $state([...])
A reactive array of fruit names.
{#each fruits as fruit}
Loops over each item, one by one. For each, we call it fruit.
<li>{fruit}</li>
Displays the fruit inside a list item.

👉 Result: an unordered list with Apple, Banana, Cherry.

Analogy: Think of {#each} like a cookie cutter 🍪. The dough is your array, and each cookie is an element produced in the DOM. Same shape, different piece.

Destructuring Inside Loops

Arrays don’t always hold just strings. Sometimes they hold objects with multiple properties. {#each} can destructure them directly.

📂 src/lib/TodoList.svelte

<script>
  let todos = $state([
    { id: 1, text: 'Learn Svelte', done: false },
    { id: 2, text: 'Build an app', done: true },
    { id: 3, text: 'Celebrate 🎉', done: false }
  ]);
</script>

<ul>
  {#each todos as { text, done }}
    <li>
      {text} {done ? '✅' : '❌'}
    </li>
  {/each}
</ul>

📂 src/routes/+page.svelte

<script>
  import TodoList from '$lib/TodoList.svelte';
</script>

<TodoList />

Breaking it down 📝

todos is an array of objects. Each has id, text, and done.
{#each todos as { text, done }} This is destructuring! Instead of writing todo.text and todo.done, we unpack them into local variables.
<li>{text} {done ? '✅' : '❌'}</li> Shows each task with a checkmark or cross.

👉 Result: You get a neat todo list. And notice how clean the code looks — no extra todo. prefix everywhere.

Using the Index

Sometimes you need to know which number in the list you’re on (0, 1, 2…). You can grab that with , i.

📂 src/lib/NumberedList.svelte

<script>
  let items = $state(['First', 'Second', 'Third']);
</script>

<ol>
  {#each items as item, i}
    <li>{i + 1}. {item}</li>
  {/each}
</ol>

📂 src/routes/+page.svelte

<script>
  import NumberedList from '$lib/NumberedList.svelte';
</script>

<NumberedList />

Breaking it down 🔢

{#each items as item, i} The second variable is the index (starting at 0).
<li>{i + 1}. {item}</li> Adds numbering before each item.

👉 Result:

First
Second
Third

Handling Empty Lists

What if the array is empty? By default, nothing renders. Sometimes that’s fine, but often you want to show a message like “No items yet.”

Svelte gives us an {:else} inside {#each}.

📂 src/lib/EmptyList.svelte

<script>
  let books = $state([]);
</script>

<ul>
  {#each books as book}
    <li>{book}</li>
  {:else}
    <li>No books found.</li>
  {/each}
</ul>

📂 src/routes/+page.svelte

<script>
  import EmptyList from '$lib/EmptyList.svelte';
</script>

<EmptyList />

Breaking it down 📚

let books = $state([]);
Starts empty.
{#each books as book} … {:else} … {/each}
If there are books, render them. Otherwise, render the {:else} branch.

👉 Result: the list shows “No books found.” until you add something to the array.

Analogy: It’s like opening your fridge 🧊. If it’s full, you see food. If it’s empty, you don’t just see nothing — you see “No groceries.”

Nested Loops

Loops can even be nested — one inside another. For example, let’s render categories with their items.

📂 src/lib/CategoryList.svelte

<script>
  let categories = $state([
    { name: 'Fruits', items: ['Apple', 'Banana'] },
    { name: 'Vegetables', items: ['Carrot', 'Lettuce'] }
  ]);
</script>

<div>
  {#each categories as category}
    <h2>{category.name}</h2>
    <ul>
      {#each category.items as item}
        <li>{item}</li>
      {/each}
    </ul>
  {/each}
</div>

📂 src/routes/+page.svelte

<script>
  import CategoryList from '$lib/CategoryList.svelte';
</script>

<CategoryList />

Breaking it down 🥗

categories is an array of objects. Each object has a name and an array of items.
Outer {#each} → loops through categories.
Inner {#each} → loops through items inside each category.
<h2> displays category names, <li> lists the items.

👉 Result:
Fruits

Apple
Banana

Vegetables

Carrot
Lettuce

Analogy: It’s like a grocery store 🛒. First you see the aisle signs (Fruits, Vegetables), then inside each aisle, you see the items.

⚠️ Warning: Deeply nested loops can get hard to read. Just like with nested conditionals, if things start looking tangled, consider splitting into smaller components.

Reactivity Reminders

With $state, arrays and objects are reactive even when you mutate them. That means things like push, pop, splice, and updating object properties will trigger the UI to update. No extra tricks required.

Let’s see it:

📂 src/lib/ReactiveTodos.svelte

<script>
  let todos = $state(['Learn Svelte', 'Build an app']);
  let newTodo = $state('');

  function addTodo() {
    const v = newTodo.trim();
    if (!v) return;

    // ✅ This works with $state: mutation is reactive
    todos.push(v);

    // (Optional alternative — also works)
    // todos = [...todos, v];

    newTodo = '';
  }
</script>

<input
  placeholder="New todo"
  bind:value={newTodo}
/>

<button on:click={addTodo}>Add</button>

<ul>
  {#each todos as todo}
    <li>{todo}</li>
  {/each}
</ul>

📂 src/routes/+page.svelte

<script>
  import ReactiveTodos from '$lib/ReactiveTodos.svelte';
</script>

<ReactiveTodos />

Breaking it down 🪄

let todos = $state([...]) makes the array reactive.
todos.push(v) is enough to update the UI. You’ll see the new item appear instantly.
Reassigning (todos = [...todos, v]) also works. Some teams prefer this style for code clarity or immutability patterns, but it’s not required for reactivity when you’re using $state.

Try it yourself:

Add a few todos and watch them render immediately.
Swap todos.push(v) with the reassignment line and confirm both approaches behave the same.
Bonus: experiment with removal via todos.splice(i, 1)—the UI will react to that mutation too.

Bonus: objects mutate reactively too

📂 src/lib/ReactionDemo.svelte

<script>
  let person = $state({ name: 'Ada', likes: 0 });
</script>

<p>{person.name} likes: {person.likes}</p>
<button on:click={() => person.likes++}>Like</button>

Clicking Like increments person.likes and the <p> updates immediately. No reassignment needed.

When might reassignment still be useful?

Code style/clarity: Some devs like immutability (always creating new arrays/objects) because it’s predictable and plays nicely with certain patterns (e.g., undo/redo).
Transformations: When you already have a new array/object (e.g., from map, filter, reduce), reassigning is natural.
Signals to readers: A reassignment can make it visually obvious “something changed” when scanning code.

Styling Lists

Lists don’t have to look boring. You can use conditionals and styling inside loops to make each item visually reflect its state.

📂 src/lib/StyledTodos.svelte

<script>
  let todos = $state([
    { text: 'Write code', done: true },
    { text: 'Test app', done: false },
    { text: 'Ship product', done: false }
  ]);
</script>

<ul>
  {#each todos as { text, done }}
    <li style="color: {done ? 'green' : 'red'}">
      {done ? '✅' : '❌'} {text}
    </li>
  {/each}
</ul>

Breaking it down 🎨

todos is now an array of objects.
We destructure { text, done } right in the loop for clarity.
If done is true → show ✅ and turn text green.
If not → show ❌ and turn text red.

👉 The list instantly communicates status: finished tasks in green, pending ones in red.

Analogy: Think of it like a teacher’s gradebook 📒. Passed students are highlighted in green, those who still owe homework are marked in red.

Try it yourself:
Change one of the todos’ done values to true or false and watch the colors flip.

Keys Matter

This is a big one. When you render a list that changes order or has items added/removed, Svelte needs to know which DOM node corresponds to which item. That’s why {#each} supports keys.

📂 src/lib/KeyedList.svelte

<script>
  let people = $state([
    { id: 1, name: 'Ada' },
    { id: 2, name: 'Grace' },
    { id: 3, name: 'Linus' }
  ]);

  function shuffle() {
    people = people.sort(() => Math.random() - 0.5);
  }
</script>

<button on:click={shuffle}>Shuffle</button>

<ul>
  {#each people as person (person.id)}
    <li>{person.name}</li>
  {/each}
</ul>

Breaking it down 🧩

The important part is (person.id). That tells Svelte: “Use id as the stable identity for this item.”
Without keys, if you shuffle the array, Svelte might reuse DOM nodes incorrectly — leading to weird glitches (like the wrong person keeping focus in an input).
With keys, each list item is “tagged” with its ID, so Svelte moves the right DOM nodes around.

Analogy: Think of a classroom seating chart 🪑. If students shuffle around but keep their name tags, the teacher still knows who’s who. Without name tags, chaos ensues.

Try it yourself:

Remove (person.id) and try shuffling. The UI still seems okay because the list is simple. But with more complex UIs (like inputs or animations), things will go wrong.
Put the keys back and breathe easy.

Performance Notes

Loops might make you worry: “What if I have thousands of items? Won’t this be slow?”

The good news: Svelte compiles loops into super-efficient code. It only updates what actually changed.

👉 For most apps: don’t worry.
👉 For really large lists (tens of thousands of rows): you might look into virtualization libraries (which only render what’s visible). That’s an advanced optimization.

Analogy: Imagine updating a giant spreadsheet 📊. Instead of rewriting the whole sheet, Svelte just changes the few cells that actually updated.

Rule of thumb: write clear loops, add keys where needed, and let Svelte handle the rest.

Mini-Project — Shopping Cart 🛒

Let’s put it all together into something more real: a shopping cart. This will use reactivity, indices, keys, empty fallbacks, and array updates.

📂 src/lib/ShoppingCart.svelte

<script>
  let cart = $state([
    { id: 1, name: 'Apple', qty: 2 },
    { id: 2, name: 'Banana', qty: 1 }
  ]);
  let newItem = $state('');
</script>

<input
  placeholder="New item"
  bind:value={newItem}
/>
<button
  on:click={() => {
    if (newItem.trim()) {
      const id = Date.now();
      cart = [...cart, { id, name: newItem, qty: 1 }];
      newItem = '';
    }
  }}
>
  Add
</button>

<ul>
  {#each cart as item, i (item.id)}
    <li>
      {i + 1}. {item.name} (x{item.qty})
      <button on:click={() => {
        cart = cart.map(it =>
          it.id === item.id ? { ...it, qty: it.qty + 1 } : it
        );
      }}>+</button>
      <button on:click={() => {
        cart = cart.filter(it => it.id !== item.id);
      }}>Remove</button>
    </li>
  {:else}
    <li>Cart is empty.</li>
  {/each}
</ul>

📂 src/routes/+page.svelte

<script>
  import ShoppingCart from '$lib/ShoppingCart.svelte';
</script>

<h1>My Cart</h1>
<ShoppingCart />

Breaking it down 🛍️

cart starts with two items. Each has id, name, and qty.
Adding an item: creates a new object with a fresh id (using Date.now() as a simple unique key).
Each row shows the item’s index, name, and quantity.
The + button increments quantity → we use .map() and reassign cart.
The Remove button deletes the item → we use .filter() and reassign cart.
The {:else} ensures that if the cart is empty, the UI says so.

👉 This tiny shopping cart ties all the loop features together: iteration, indices, keys, reactivity, and empty handling.

Analogy: It’s like managing a real basket at the store 🛒. Add things, increase amounts, remove them. The basket always shows what’s inside, and if it’s empty, it tells you so.

Try it yourself:

Add “Orange” → it appears with quantity 1.
Click + → it bumps to 2.
Remove Banana → gone.
Remove everything → “Cart is empty.”

Wrapping Up 🎁

We’ve covered a lot in this journey through loops. Let’s summarize:

{#each} → repeat a block for each item.
Destructuring → makes code cleaner.
Indices → , i gives you the position.
Empty lists → add {:else} so the UI isn’t blank.
Nested loops → useful, but don’t overdo it.
Reactivity → with $state, both mutation and reassignment are reactive; pick the one that’s clearest for your codebase.
Keys → crucial for stable updates when items move or change.
Performance → Svelte is efficient, you usually don’t need to worry.

👉 Big picture: loops + conditionals = dynamic UIs that respond to any amount of data.

At this point, your Svelte toolkit covers:

Props (passing data down).
Events (sending messages up).
Conditionals (making decisions).
Loops (handling collections).

That’s a solid foundation for building almost anything. 🚀

Next up in this series, we’ll build on these fundamentals to tackle more advanced patterns — but for now, give yourself a pat on the back. You’ve gone from rendering one thing to rendering entire collections like a pro. 🎉

Next article: Styling in Svelte (Scoped CSS, :global, and Class Directives)

Conditionals in Svelte — {#if}, {:else}, and Nesting Explained

Ali Aslam — Sun, 07 Sep 2025 05:06:42 +0000

Imagine opening an app and always seeing the same thing, no matter who you are or what you’ve done.

You’re logged out? Still says “Welcome back!”.
You’re logged in? Still says “Please log in.”.
You’re waiting for something to load? The app just… stares blankly at you.

Not great, right?

This is why we need conditional rendering: the ability to show (or hide) parts of the UI depending on what’s going on. Think of it like stage lighting 🎭: only the actors relevant to the current scene get the spotlight.

In this article we’ll explore:

How to show something only if a condition is true.
How to add an else branch.
How to handle multiple cases with else if.
How to nest conditions carefully.
Common gotchas you might trip on.

And, as always: no prior knowledge assumed. Every example will be fully explained, copy-paste ready, with file paths included.

Step 1: The `{#if}` Block

The simplest conditional is just an “if this is true, then show this.”

📂 src/lib/Welcome.svelte

<script>
  let loggedIn = $state(false);
</script>

{#if loggedIn}
  <h1>Welcome back!</h1>
{/if}

<button on:click={() => (loggedIn = !loggedIn)}>
  {loggedIn ? 'Logout' : 'Login'}
</button>

📂 src/routes/+page.svelte

<script>
  import Welcome from '$lib/Welcome.svelte';
</script>

<Welcome />

Breaking it down 🪄

let loggedIn = $state(false);
This is our little “switch.” Starts at false, meaning “user not logged in.” Because it’s $state, the UI will update whenever it changes.
{#if loggedIn} ... {/if}
Only runs the inside code if the condition is true. If loggedIn is false, it renders nothing at all.
The <button>
Flips loggedIn between true and false. We even change the button label with a ternary (loggedIn ? 'Logout' : 'Login').

👉 Try it: load the page, click the button. The <h1> pops in and out of existence! You’ve just made your UI dynamic.

Analogy time: it’s like a light switch 💡. If loggedIn is on (true), the lamp shows. If it’s off (false), the lamp vanishes.

Step 2: Adding `{:else}`

Okay, but right now, when you’re logged out, the screen goes blank. That’s like a party host who only greets people they know — otherwise they just… stare at you. Awkward.

We can fix that with {:else}:

📂 src/lib/Welcome.svelte

<script>
  let loggedIn = $state(false);
</script>

{#if loggedIn}
  <h1>Welcome back!</h1>
{:else}
  <h1>Please log in</h1>
{/if}

<button on:click={() => (loggedIn = !loggedIn)}>
  {loggedIn ? 'Logout' : 'Login'}
</button>

📂 src/routes/+page.svelte

<script>
  import Welcome from '$lib/Welcome.svelte';
</script>

<Welcome />

Breaking it down 🧩

Two branches, one outcome.
If loggedIn is true → show “Welcome back!”.
If not → show “Please log in”.
UI is never empty.
Someone always has the spotlight — either the logged-in actor or the logged-out one.

Analogy: It’s like a friendly doorman 🚪. If they recognize you, they say “Welcome back!”. If they don’t, they politely say “Please log in.”. There’s always a response.

👉 Try it: toggle the button and watch the messages swap back and forth.

Step 3: `{:else if}` for Multiple Cases

Life isn’t always binary. Sometimes we need three or more states.

Example:

While data is loading → show “Loading…”
Once loaded and user is authenticated → show “Welcome back!”
Otherwise → show “Please log in.”

📂 src/lib/AuthStatus.svelte

<script>
  let status = $state('loggedOut');

  function setLoading() {
    status = 'loading';
    setTimeout(() => {
      status = 'loggedOut';
    }, 2000);
  }

  function login()  { status = 'loggedIn'; }
  function logout() { status = 'loggedOut'; }
</script>

{#if status === 'loading'}
  <p>Loading…</p>
{:else if status === 'loggedIn'}
  <p>Welcome back!</p>
{:else}
  <p>Please log in.</p>
{/if}

<div style="margin-top: 1rem;">
  <button on:click={setLoading}>Set Loading</button>
  <button on:click={login}>Login</button>
  <button on:click={logout}>Logout</button>
</div>

📂 src/routes/+page.svelte

<script>
  import AuthStatus from '$lib/AuthStatus.svelte';
</script>

<AuthStatus />

Breaking it down 🎛️

status = $state('loading')
Our variable can hold "loading", "loggedIn", or "loggedOut".
{#if …} {:else if …} {:else}
Works just like a traffic light 🚦:
- If red (loading), show “Loading…”
- If green (loggedIn), show “Welcome back!”
- Otherwise (yellow = loggedOut), show “Please log in.”
Buttons let us simulate flipping between states. Notice how the UI updates instantly with each change.

👉 Try it yourself:

Click “Set Loading.” You’ll see “Loading…” for 2 seconds, then it flips to “Please log in.”
Click “Login.” UI now says “Welcome back!”
Click “Logout.” UI says “Please log in.”

You’ve just seen conditional rendering handle multiple possibilities like a champ.

Step 4: Nesting Conditionals (with Care)

Sometimes conditions depend on two things at once. For example:

Is the user logged in?
And if yes, are they an admin?

📂 src/lib/UserStatus.svelte

<script>
  let loggedIn = $state(false);
  let isAdmin  = $state(false);

  function loginAsUser()  { loggedIn = true;  isAdmin = false; }
  function loginAsAdmin() { loggedIn = true;  isAdmin = true;  }
  function logout()       { loggedIn = false; isAdmin = false; }
</script>

{#if loggedIn}
  {#if isAdmin}
    <p>Welcome, mighty admin!</p>
  {:else}
    <p>Welcome, regular user.</p>
  {/if}
{:else}
  <p>Please log in.</p>
{/if}

<div style="margin-top: 1rem;">
  <button on:click={loginAsUser}>Login as User</button>
  <button on:click={loginAsAdmin}>Login as Admin</button>
  <button on:click={logout}>Logout</button>
</div>

📂 src/routes/+page.svelte

<script>
  import UserStatus from '$lib/UserStatus.svelte';
</script>

<UserStatus />

Breaking it down 🧩

We track two pieces of state: loggedIn and isAdmin.
If not logged in → show “Please log in.”
If logged in and admin → show “Welcome, mighty admin!”
If logged in but not admin → show “Welcome, regular user.”

👉 Analogy: It’s like a club entrance 🚪. First the bouncer checks if you’re on the guest list (logged in). If yes, they check your VIP pass (admin). Depending on both, you get different treatment.

⚠️ Warning: Nesting {#if} blocks inside each other can get messy fast. If you find yourself stacking three or four deep, it may be time to restructure your code (e.g. combine conditions into a single variable, or split logic into smaller components).

Step 5: Common Gotchas

Conditionals are simple on the surface, but beginners often trip over the same issues. Let’s clear them up.

1) Truthy and Falsy Values

📂 src/lib/CounterCheck.svelte

<script>
  let count = $state(0);
</script>

{#if count}
  <p>Count is nonzero: {count}</p>
{:else}
  <p>Count is zero</p>
{/if}

<button on:click={() => count++}>Increment</button>

👉 Remember: in JavaScript, 0 is falsy. So {#if count} won’t show until count becomes 1 or more.

It’s like asking “Do we have cookies?” If the jar is empty (0), the answer is no. Only once there’s at least one cookie does the conditional pass. 🍪

2) Automatic Reactivity

📂 src/lib/ToggleExample.svelte

<script>
  let visible = $state(false);
</script>

{#if visible}
  <p>You can see me now!</p>
{:else}
  <p>Now I’m hidden.</p>
{/if}

<button on:click={() => (visible = !visible)}>
  Toggle
</button>

👉 You don’t need to “force” a re-render.
When visible changes, Svelte automatically re-evaluates the {#if} and updates the DOM.

Think of it like a thermostat 🌡️. You don’t tell the heater “re-render the room!”. You just change the temperature setting, and the system adjusts itself.

3) Performance

Worried about performance? Don’t be (at least not yet). Svelte compiles these {#if} blocks into super efficient code. Unless you’re toggling thousands of elements every frame, you’re fine.

Step 6: Quick Recap

We’ve covered a lot of ground! Let’s review:

{#if} → show something only when a condition is true.
{:else} → provide a fallback when the condition is false.
{:else if} → handle multiple possibilities in sequence.
Nesting → possible, but keep it tidy.
Gotchas → remember truthy/falsy rules and trust Svelte’s reactivity.

👉 Big picture: conditional rendering makes your UI context-aware. Your app can respond to state changes and show the right thing at the right time.

What’s Next?

We’ve now taught our app how to make decisions. But sometimes we don’t want to choose one thing — we want to render a list of things.

For that, we’ll need loops. And that’s exactly what we’ll tackle in the next article. 🚀

Next article: Loops in Svelte — {#each}, Keys, and Building a Todo App

Forem: Ali Aslam

Mastering Svelte Lifecycle Hooks & Accessibility: Essential Tips for Building Dynamic, Accessible Apps

Part A — Lifecycle Hooks ⏱️

onMount

$effect.pre (before DOM update)

$effect (after DOM update)

onDestroy

Mini Recap 📝

Part B — Accessibility (a11y) ♿

ARIA Roles 🎭

Keyboard Navigation ⌨️

Focus Management 🎯

Labels & Inputs 🏷️

Color Contrast 🎨

Live Regions 🔊

Real-World Example: Accessible Tabs 🗂️

Usage

Accessible Modal (Mini Project) 🪟♿

Modal Component

Using the Modal

Why this is accessible

Mastering DOM Manipulation with Svelte Actions and Children

Why Actions? 🎬

Stores vs Actions

The problem

The idea

Your First Action: Autofocus 👀

Action file

Usage in a page

How it works

Actions with Cleanup 🧹

Example: Click Outside Detector

Usage in a component

Why this works

Actions with Parameters 🎛️

Example: Resize Box

Usage in a page

How it works

Advanced Actions (Extra Examples) 🚀

1. Debounced Input ⏳

Usage

2. Drag and Drop (Basic) 🖱️

Usage

Mini Recap 📝

Extra Notes for Beginners

Why Children? 👶

Default Children 📦

Example: Card Component

Using the Card

Named Children 🧁

Example: Layout Component

Using the Layout

Fallback Children 📝

Example: Button Component

Using the Button

Children as Render Functions (Child → Parent) 🔄

Example: List Component

Using the List

Gotchas & Best Practices ⚠️

Mastering Svelte Custom Stores

Step 1 — Quick recap: basic stores 🧰

Create the simplest store (a counter)

Use the store in a page/component

Alternative ways to update the store

Important caveats & beginner tips

Step 2 — Why Custom Stores? 🤔

Step 3 — The simplest custom store 🛠️

The recipe for a custom store

Store file

Component using the store

✅ Now notice

💡 A helpful analogy

Step 4 — Adding constraints & business rules ⚖️

Store with constraints + history

Using the store in a page

What’s happening here?

✅ Benefits

Beginner note

Step 5 — Persistent stores with localStorage 💾

The SvelteKit Catch 🤯

`onMount`

`$effect.pre` (before DOM update)

`$effect` (after DOM update)

`onDestroy`

Step 5 — Persistent stores with `localStorage` 💾

`<form method="POST">`

`name="..."` on inputs

`required` and `type="email"`

`let { form } = $props();`

`{#if form?.message}`

Step 1 — Meet `use:enhance`

Step 1: The `routes` Folder

Step 2: `+page.svelte`

Step 8: Universal `load` — Runs on Server and Client

Why use `+page.server.js` here?

Key difference vs. `+page.js`