DEV Community: Denys Sych

Svelte journey | SvelteKit: Page options, Link Options, Environment variables

Denys Sych — Sat, 13 Jan 2024 09:23:46 +0000

Welcome,

In this article, we will focus on how to fine-tune preloading and prerendering functionalities, as well as effectively manage environment variables in SvelteKit.

If you’ve been following the series from the beginning, congratulations — you've put in great effort, and this marks the final installment of the series! If not, I would strongly recommend taking a glance through the previous articles; you may still find something interesting.

So, let’s get started.

Page Options

This section explores the fine-tuning of preloading, prerendering, and other functionalities in SvelteKit. It details how to export options and discusses specific page options, such as disabling SSR, client-side rendering, and defining trailing slashes.

Options can be exported from +page.js, +page.server.js, +layout.js, and +layout.server.js, but it actually works when exports happen from +<type>.server.js:
- E.g., export const ssr = false;
- Page options can be applied for an individual page or layout;
- To apply globally, export options from the root layout;
- More nested definitions override inherited ones.

We can export the following options:

ssr — to disable SSR;
- If you define export const ssr = false; in a non-server file, it may not make much sense. When defined in a plain page or layout, it may not be helpful in case of interaction with browser-related API. For example, when you load an app from / and navigate to /bar which uses the window object, it would work. But if you then reload the browser tab on /bar, you get a 500 Error, window is undefined, and an error would be thrown;
- ssr = false in src/routes/+layout.server.js transforms the entire app into a SPA.
```
// bar/+page.svelte
<script>
    export const ssr = false; // will really make a difference in +page.server.js. Here it may be useless
</script>
<h1>{window.innerWidth}x{window.innerHeight}</h1>
```
csr — to disable client-side rendering (no JS is served to the client);
- Same story as with ssr and not server suffixed files;
prerender — prepare HTML for a page only once, not dynamically for each request (build static HTML on the build step). false by default;
- ssr = false in src/routes/+layout.server.js transforms the entire app into a SSG;
- Can be configured;
trailingSlash — we have two URLs: /foo and /foo/. We have a relative URL ./bar. For /foo, it would be /bar, for /foo/, it would be /foo/bar.
- By default, SvelteKit strips trailing slashes out, so /foo/ will result in a redirect to /foo;
- export const trailingSlash = 'always' | 'ignore' | 'never' — never is by default, better leave as is;
- Trailing slashes are applied affects pre-rendering. A URL like /always/ will be saved to disk as always/index.html whereas a URL like /never will be saved as never.html.

Link (Route) Options

Delving into the tuning of page loading accessible by links, this section covers various attributes for preloading tuning.

Implemented as attributes;
Cascade application (if applied on some parent → will be applied for all anchor children;
To prevent cascade behavior, you can set the attribute to false in a required place, e.g.:

<div data-sveltekit-preload-data>
    <a href="/a">a</a>
    <div data-sveltekit-preload-data="false">
        <a href="/b">b</a>
    </div>
</div>

Preloading

“Anticipate” that the link would be used → starts to fetch the resource behind the link when the anchor is hovered (or tapped on mobile). Need to add data-sveltekit-preload-data attribute.

Attribute’s values can have values: "hover" (default) | "tap" (default for mobile) | "off";
Can be placed on <a /> or any element whose has <a /> as a child;
<body data-sveltekit-preload-data> is by default in the generated project;

<nav>
    <a href="/">home</a>
    <a href="/chart" data-sveltekit-preload-data>Chart</a>
</nav>

Alternative attribute: data-sveltekit-preload-code — preloads code for the route without loading its data. Possible values:

"eager" — preload everything on the page following navigation;
"viewport" — preload everything as it appears in the viewport;
"hover" | "tap" | "off" — same as for data-sveltekit-preload-data.

Programmatic Preload

The same purpose but can be done in pages and layouts:

import { preloadCode, preloadData } from '$app/navigation';
preloadData('/foo');
preloadCode('/bar');

Other Options

data-sveltekit-noscroll — do not scroll to the top on navigation;
data-sveltekit-keepfocus — do not reset focus on navigation;
data-sveltekit-replacestate — replace the browser’s history instead of pushing one more step;
data-sveltekit-reload — full-page reload (or it can be rel="external” attribute on an anchor)

Environment Variables Access — `$env` Module

Variables should be defined in a .env file, in the root folder.

Private Variables

.env.[mode] files are also supported according to Vite documentation;
In an app, variables are accessible via $env/static/private;
Variables from process.env are also available from $env/static/private;
Env. variables only accessible in server modules:
- Any +page.server.js | +layout.server.js | +server.js, any files ending with server.js;
- Any files inside src/lib/server;

Static vs Dynamic

Previously mentioned $env/static/private — these variables are known at a build time — it helps Svelte to optimize the code, so static are more preferable.

Dynamic ones are not known until the app is running. It means no optimizations from Svelte’s side;
From the dev’s perspective, you just need to use $env/dynamic/private import instead of static one;
Dynamic variables are accessible via env object:

import { env } from '$env/dynamic/private';
// env.API_TOKEN

Public Variables

The variables that can be safely exposed to the client side.

Their naming must start from PUBLIC_ prefix, e.g., PUBLIC_MAPBOX_KEY ;
Import them through $env/static/public or $env/dynamic/public:

import { PUBLIC_MAPBOX_KEY } from '$env/static/public';
import { env } from '$env/dynamic/public';

Final words

We've concluded our journey through this impressive toolkit crafted by the Svelte team, known for its exceptional developer experience and user-centric design. While we've covered substantial ground, there's still a wealth of features to discover. I trust this exploration has sparked your interest to delve deeper into the possibilities it offers.

It's a well-designed tool that should bring joy to both creators and consumers — a goal definitely achieved by the Svelte team.

If you want to join the community, there is a Discord server at svelte.dev/chat and Reddit's r/sveltejs.

I hope you've enjoyed this Svelte journey and have gained a general understanding of what the Svelte toolkit is all about.

Take care, go Svelte.

Resources

Svelte journey | SvelteKit: Server-side, SvelteKit utility stores, Error handling, Hooks

Denys Sych — Thu, 11 Jan 2024 17:00:00 +0000

Welcome,

In the previous part, we started to explore SvelteKit, and today we’ll continue on that. The previous chapter touched on routing, data loading, and the concept of shared modules in SvelteKit.

This article will focus on server-side interaction, specifically API Routes, which are included in SvelteKit. We will also cover form submitting actions with progressive enhancement, specific stores built into the kit, and error handling.

Lastly, we will discuss hooks that help customize default SvelteKit mechanisms for data loading and error handling.

Forms — server-side interaction without client-side JS execution

A form is a standard tool for sending data back to the server:

// src/routes/+page.svelte
<form method="POST">
    <label>
        add a todo:
        <input
            name="description"
            autocomplete="off"
        />
    </label>
</form>

To handle this on the server-side, actions should be used inside +page.server.js. The request is a standard Request object, and await request.formData() returns a FormData instance:

// src/routes/+page.server.js
export function load() {
    // ...
}

export const actions = {
  // Unnamed form = default action
    default: async ({ cookies, request }) => {
        const data = await request.formData();
        db.createTodo(cookies.get('userid'), data.get('description'));
    }
};

No JS fetching here → the application operates even with disabled JS.

Named form actions

Default actions cannot coexist with named actions;
The action attribute can be any URL. If the action was defined on another page, you might have something like /todos?/create;
When the action is on this page, we can omit the pathname altogether and use just ?;
After an action runs, the page will be re-rendered, and the load action will run after the action completes;
Actions are always about POST requests.

// src/routes/+page.svelte
<form method="POST" action="?/create">
    <label>
        add a todo:
        <input
            name="description"
            autocomplete="off"
        />
    </label>
</form>

// src/routes/+page.server.js
export const actions = {
  // action="?/create"
    create: async ({ cookies, request }) => { // ...    }
};

Markup-based validation

The most basic one, like required in <input name="title" required />.

Server-side validation

The common flow is as follows:

Throw new Error() from a service (e.g., src/lib/server/database.js);
Catch this error in +page.server.js (e.g., src/routes/+page.server.js);
Show the error in +page.js by accessing the form's metadata through export let form.

// src/lib/server/database.js
export function createTodo(userid, description) {
    if (description === '') {
        throw new Error('todo must have a description'); // 1. Throw an error
    }
}

// src/routes/+page.server.js
import { fail } from '@sveltejs/kit';
import * as db from '$lib/server/database.js';

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

        try {
            db.createTodo(cookies.get('userid'), data.get('description'));
        } catch (error) {
            return fail(422, { // 2. Catch and return expected failure
                description: data.get('description'),
                error: error.message
            });
        }
    }
};

// src/routes/+page.svelte
<script>
    export let data;
    export let form;
</script>

<div class="centered">
    <h1>todos</h1>

    {#if form?.error} // 3. Handle an error
        <p class="error">{form.error}</p>
    {/if}

    <form method="POST" action="?/create">
        <label>
            add a todo:
            <input
                name="description"
                value={form?.description ?? ''}
                autocomplete="off"
                required
            />
        </label>
    </form>
</div>

Instead of using fail, you can also perform a redirect or just return some data — it will be accessible via form.

Progressive enhancement `use:enhance` — SPA-like API interaction

When JS is enabled in a client's environment, Svelte progressively enhances the functionality without full-page reloads. The same happens with <a/> anchor navigations.

Updates the form prop;
Invalidates all data on a successful response, causing load functions to re-run;
Navigates to the new page on a redirect response;
Renders the nearest error page if an error occurs.

<script>
    import { enhance } from '$app/forms';
</script>

<form method="POST" action="?/create" use:enhance>
    <!-- Form content -->
</form>

Customised enhancing for optimistic updates, pending states, etc.

For example, there is usually some delay in server-to-client communication, which requires loading states.

Pass a callback to use:enhance to handle such cases:

<script>
    import { fly, slide } from 'svelte/transition';
    import { enhance } from '$app/forms';

    export let data;
    export let form;

    let creating = false;
    let deleting = [];
</script>

<form
    method="POST"
    action="?/create"
    use:enhance={() => { // <--- custom handling happens here
        creating = true;
        return async ({ update }) => {
            await update();
            creating = false;
        };
    }}
>
  {#if creating}
      <span class="saving">saving...</span>
  {/if}
    <label>
        add a todo:
        <input
            disabled={creating}
            name="description"
            value={form?.description ?? ''}
        />
    </label>
    <!-- Additional form elements -->
</form>

More details on use:enhance can be found here. An extract from the documentation:

<form
    method="POST"
    use:enhance={({ formElement, formData, action, cancel, submitter }) => {
        // `formElement` is this `<form>` element
        // `formData` is its `FormData` object that's about to be submitted
        // `action` is the URL to which the form is posted
        // Calling `cancel()` will prevent the submission
        // `submitter` is the `HTMLElement` that caused the form to be submitted

        return async ({ result, update }) => {
            // `result` is an `ActionResult` object
            // `update` is a function that triggers the default logic that would be triggered if this callback wasn't set
        };
    }}
>
    <!-- Form content -->
</form>

API Routes

SvelteKit allows you to define API routes that handle server-side functionality. These routes can be used to fetch data from databases, interact with external APIs, file system etc. or perform any other server-side operations. This makes it seamless to integrate your frontend with backend functionality.

Supports all default HTTP methods: GET, PUT, POST, PATCH and DELETE. Function name in +server.js should be the same as the method name;
Request handlers must return a Response object;
From the client (+page.js), you need to make requests as from usual JS code;

// src/routes/todo/+server.js
import { json } from '@sveltejs/kit';
import * as database from '$lib/server/database.js';

export async function GET() {
    return json(await database.getTodos());
}

export async function POST({ request, cookies }) {
    const { description } = await request.json();
    const userid = cookies.get('userid');
    const { id } = await database.createTodo({ userid, description });

    return json({ id }, { status: 201 });
}

// src/routes/todo/+page.svelte
<script>
    export let data;
</script>
<!-- Additional page content -->
<input
    type="text"
    autocomplete="off"
    on:keydown={async (e) => {
        if (e.key !== 'Enter') return;
        const input = e.currentTarget;
        const description = e.currentTarget.value;

        const response = await fetch('/todo', {
            method: 'POST',
            body: JSON.stringify({ description }),
            headers: {
                'Content-Type': 'application/json'
            }
        });

        const { id } = await response.json();

        data.todos = [...data.todos, {
            id,
            description
        }];

        input.value = '';
    }}
/>

Stores

We’ve met stores before, now we are going to see predefined, readonly stores in SvelteKit. There are three of them: page, navigating, and updated. They are available via $app/stores module.

Page

Provides information about the current page:

url — the URL of the current page;
params — the current page's parameters;
route — an object with an id property representing the current route;
status — the HTTP status code of the current page;
error — the error object of the current page, if any;
data — the data for the current page, combining the return values of all load functions;
form — the data returned from a form action.

// src/routes/+layout.svelte
<script>
    import { page } from '$app/stores';
</script>

<nav>
    <a href="/" class:active={$page.url.pathname === '/'}>
        home
    </a>
    <a href="/about" class:active={$page.url.pathname === '/about'}>
        about
    </a>
</nav>

<slot />

Navigating

The navigating store represents the current navigation:

from and to — objects with params, route and url properties;
type — the type of navigation:
- form: The user submitted a <form>;
- leave: The app is being left either because the tab is being closed or a navigation to a different document is occurring;
- link: Navigation was triggered by a link click;
- goto: Navigation was triggered by a goto(...) call or a redirect;
- popstate: Navigation was triggered by back/forward navigation;
willUnload — Whether or not the navigation will result in the page being unloaded (i.e. not a client-side navigation);
delta? — in case of a history back/forward navigation, the number of steps to go back/forward;
complete — promise that resolves once the navigation is complete, and rejects if the navigation fails or is aborted. In the case of a willUnload navigation, the promise will never resolve.

// src/routes/+layout.svelte
<script>
    import { page, navigating } from '$app/stores';
</script>
<!-- Additional layout content -->
{#if $navigating}
    navigating to {$navigating.to.url.pathname}
{/if}

Updated

The updated store contains true or false depending on whether a new version of the app has been deployed since the page was first opened. For this to work, your svelte.config.js must specify kit.version.pollInterval.

Errors and Redirects

We can either throw error or redirect (import { redirect, error } from '@sveltejs/kit' , e.g. throw redirect(307, '/maintenance'). redirect can be called:

inside load functions;
form actions;
API routes;
handle hook (described in the next section).

The most common status codes:

303 — form actions, after a successful submission;
307 — temporary redirects;
308 — permanent redirects.

Hooks

A way to intercept and override the framework's default behaviour. Can be also named as interceptors at some point.

there are two types of hooks: server (should be in src/hooks.server.js) and client (src/hooks.server.js) ones. They also can be shared (environment-specific) and universal (run both on client and server);
mentioned file paths are by default, it can be customized via config.kit.files.hooks.

`handle` hook

server hook only;
runs every time server receives a request and modifies the response (runtime and pre-rendering);
requests to static assets and already pre-rendered pages — not handled by SvelteKit;
multiple handle hooks can be added via sequence utility function;

export async function handle({ event, resolve }) {
    return await resolve(event, optionalParams);
}

resolve — SvelteKit matches the incoming request URL to a route of your app, imports the relevant code (+page.server.js and +page.svelte files and so on), loads the data needed by the route, and generates the response;

`event` object in server hooks

event object passed into handle is the same object — an instance of a [RequestEvent](<https://kit.svelte.dev/docs/types#public-types-requestevent>) — that is passed into API routes in +server.js files, form actions in +page.server.js files, and load functions in +page.server.js and +layout.server.js.

It has inside:

cookies — the cookies API;
fetch — the fetch API with extra perks that are described in handleFetch hook (and can be modified by this hook);
getClientAddress() — a function to get the client's IP address;
isDataRequest — true if the browser is requesting data for a page during client-side navigation, false if a page/route is being requested directly;
locals — a place to put arbitrary data. Useful pattern: add some data here so it can be accessed in subsequent load functions;
params — the route parameters;
request — the Request object;
route — an object with an id property representing the route that was matched;
setHeaders(...);
url — a URL object representing the current request.

`event.fetch` extra functionality

make credentialed requests on the server, as it inherits the cookie and authorization headers from the incoming request;
relative requests on the server (without providing origin);
internal requests (e.g. for +server.js routes) run internally, without actual HTTP call.

`handleFetch` hook

The hook that allows modifying event’s fetch behaviour.

server hook only;

export async function handleFetch({ event, request, fetch }) {
    const url = new URL(request.url);
    return url.pathname === '/foo' ? fetch('/bar') : fetch(request);
}

`handleError` hook

Interceptor for unexpected errors.:

it is shared hook — can be added to src/hooks.server.js and src/hooks.client.js;
can be used to log an error somewhere or some other side effect;
the default message can be either ‘Internal error’ or ‘Not found’. This hook allows customizing the message and the error object itself;
it never throws an error.

export function handleError({ event, error }) {
    return {
        message: 'Unknown error happened!',
        code: generateCode(error)
    };
}

`reroute` hook

universal hook, can be added to src/hooks.js;
allows you to change how URLs are translated into routes;
src/routes/[[lang]]/about/+page.svelte page → /en/about or /de/ueber-uns, /fr/a-propos. Achieavable with reroute:

const translated = {
    '/en/about': '/en/about',
    '/de/ueber-uns': '/de/about',
    '/fr/a-propos': '/fr/about',
};

export function reroute({ url }) {
    if (url.pathname in translated) {
        return translated[url.pathname];
    }
}

That's all for today, and it's a massive chunk – well done! Just a couple more steps, and we're ready to dive into our own projects with confidence, armed with new knowledge.

Take care, go Svelte!

Resources

Svelte 4 journey | SvelteKit: Introduction, Routing, Data Loading, Shared Modules

Denys Sych — Fri, 05 Jan 2024 07:30:38 +0000

Welcome,

This article marks the beginning of our exploration of @sveltejs/kit! SvelteKit is a metaframework that contains the core toolset needed to build a variety of applications. In this article, we embark on a journey through key aspects: Routing, Data Loading, and Shared Modules, unveiling the power and simplicity that SvelteKit brings to web development.

General Information

SvelteKit, a robust framework, offers a seamless transition from Server-Side Rendering (SSR) to a Single Page Application (SPA) after the initial load. Default configuration files, such as svelte.config.js and vite.config.js, along with a well-defined folder structure in /src, provide a solid foundation for building modern web applications. The /routes directory, following filesystem-based routing, makes navigation intuitive and efficient.

SSR by default → improved load performance, SEO-friendly:
- Transitions to SPA after the initial load;
- Still, this can be configured if needed.
Default configuration files in the root folder:
- svelte.config.js;
- vite.config.js;
- package.json, .prettierrc, etc.
Default folder structure:
- /src
  - /app.html — page template file;
  - /app.d.ts — app-wide interfaces (for TypeScript);
  - /routes — the routes of the app;
  - /lib — files that can be imported via $lib alias in this folder;
- /static — for any assets used in the app.

Routing

SvelteKit's routing system is structured, with each +page.svelte file inside src/routes creating a corresponding page in the app. This approach simplifies route structuring and allows for easy parameterization using square brackets in the file path.

SvelteKit uses filesystem-based routing — the route path is the same as the folder path.

Route structuring | `+page.svelte`

Every +page.svelte file inside src/routes creates a page in the app.

e.g. src/routes/+page.svelte → /, src/routes/about/+page.svelte → /about

Common layout | `+layout.svelte`

To have a common layout for some of the routes, you need to create a +layout.svelte file in the topmost folder that shares this layout. You need to specify the common layout here and put the <slot /> element to indicate where pages should mount.

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

// src/routes/+layout.svelte
<nav>
    <a href="/">home</a>
    <a href="/about">about</a>
</nav>

<slot /> // mount node for / and /about pages

Route parameters

The file path should contain a folder with a name in square brackets — its name is the parameter’s name.

src/routes/blog/[slug]/+page.svelte // single dynamic parameter
src/routes/blog/[bar]x[baz]/+page.svelte // multiple dynamic parameters (allowed with some static literal as a separator)

Example:

// src/routes/+page.svelte
<a href="/param1xparam2">Navigate</a>

// src/routes/[bar]x[baz]/+page.svelte
<script>
    import { page } from '$app/stores';
    let bar = $page.params.bar;
    let baz = $page.params.baz;
</script>
bar: {bar} | baz: {baz} // bar: param1 | baz: param2

Optional parameters

For example, you can have the locale as /fr/..., but you can also have a default locale that is not represented in the path. In that case, the parameter should be in double square brackets:

// src/routes/[[lang]]/+page.server.js
export function load({ params }) {
    return { lang: params.lang ?? 'en' };
}

Rest (any number of unknown) parameters

To match an unknown number of path segments, use a [...rest] parameter. This is useful to catch unhandled routes, similar to the * route definition in other routers.

Rest parameters do not need to go at the end — a route like /items/[...path]/edit or /items/[...path].json is totally valid.

Param matchers — validate route parameter

Param matchers allow you to validate parameters. For example, if the user ID should be numeric only, you can do the following:

Create src/params/<checker-name>.js.
Define the checker for a route param src/routes/<route>/[param=<checker-name>].

// src/params/id-matcher.js
export const match = (value) => /^[0-9]+$/.test(value);
// src/routes/user/[id=id-matcher]

In case of a failed match, a 404 error is returned.
Matchers run both on the server and the client side.

Route groups — subset of routes without changing a route’s path

Layouts are a way to share UI and data loading logic between different routes. If we need to use a layout without sharing data loading logic and without keeping the folder-to-path structure, we use route groups.

For example, our /app and /account routes are behind authentication, while /about should be available without that one. This allows us to omit routes like /authed/app and keep just /app.

Create a folder (group) with a name inside brackets, e.g., src/routes/(authed)/+layout.server.js

Unlike normal directories, route groups do not affect the URL pathname of the routes inside.

Breaking out of layouts — independent children layout

Layouts are inherited by default. If you need to break this and have an independent layout:

To break out, you need to add @ to the page naming:
- page@.svelte will reset all the hierarchy (except the root layout).
- page@<route-path-folder-name>.svelte will reset to the <route-path-folder-name> layout.
- +layout.svelte in the root cannot be broken out.

Data loading

Efficient data loading is a cornerstone of SvelteKit. The load function, available in various files like +page.js, +layout.svelte, and their server-side counterparts, empowers developers to fetch data dynamically. This data can then be seamlessly consumed in the corresponding Svelte files, providing a smooth integration of dynamic content.

The load({ url, route, params }) function in +page.js, +page.server.js, +layout.server.js, +layout.js allows you to fetch data.
It should then be consumed in the related Svelte file via <script> export let data; </script>.
$page.data is an alternative way to access the page's data or if you need to access the page's data in the layout or in children. The +page.svelte component, and each +layout.svelte component above it, has access to its own data plus all the data from its parents:
```
<script>
    import { page } from '$app/stores';
</script>

<svelte:head>
    <title>{$page.data.title}</title>
</svelte:head>
```
Files without the suffix .server. run on both the client and server (unless you put export const ssr = false inside), while files with this suffix run on the server only (you can interact with DBs, use secrets here, etc.). More details on that: universal vs server. It is also covered further in the Universal load functions section.

Page data | `+page.server.js`

The +page.server.js file should be placed next to the target +page.svelte. This file runs only on the server, including client-side navigations.
The +page.server.js file itself can import other non-Svelte files to fetch data.
If you need to handle errors (e.g., incorrect route path), you can throw an error from @sveltejs/kit.

// src/routes/blog/mocked-data.js (more realistic: import * as posts from '$lib/server/posts.service.js';
export const posts = [
    {
        slug: 'welcome',
        title: 'Welcome!',
        content:'<p>Nice that you are here</p>'
    }
];

// src/routes/blog/[slug]/+page.server.js
import { posts } from '../mocked-data.js'; // get data with some service
import { error } from '@sveltejs/kit';

export function load({ params }) { // function name must be load
    const post = posts.find((post) => post.slug === params.slug);

    if (!post) throw error(404, 'no post'); // throw an error if not found

    return { post };
}

// src/routes/blog/[slug]/+page.svelte
<script>
    export let data; // access point to exported values from +page.server.js
</script>

<h1>blog post</h1>
<h1>{data.post.title}</h1>
<div>{@html data.post.content}</div>

Layout data | `+layout.server.js`

We can load data not only for some page but also for a child route under the same layout. The mechanism is the same as for page data.

From navigation to navigation, it is usually needed to refresh the data. Invalidation should help there.

Universal load functions — when data does not come directly from your server

Load from +page.server.js and +layout.server.js is a good use-case when getting data directly from a database or reading cookies, dealing with secrets. When you deal with some data loading during client-side navigation, you may simply not need to hit your server directly but rather some other source. For example:

You need to access some external, 3rd party API.
Use in-memory data if some data persists here, and only go to the server if no in-memory data is available.
You need to return something non-serializable from the load function, such as a referenced JS object, component, store, etc.

To have such behavior, your load functions should not be in +page.js or +layout.js (no .server. suffix). With that:

Functions will run on the server during server-side rendering.
They will also run in the browser when the app hydrates or the user performs a client-side navigation.

Server `load` and universal `load` together = server → universal → page data

When using both server load and universal load, the server load return value is not passed directly to the page, but to the universal load function as the data property.

Access parent’s `load` result inside own `load` function

+page.svelte and +layout.svelte components have access to everything returned from their parent load functions. But how to access the parent's data right in the load function? We just need to use the parent prop as follows:

// src/routes/+layout.server.js
export const load = () => ({ a: 1 });

// src/routes/sum/+layout.js
export async function load({ parent }) {
    const { a } = await parent();
    return { b: a + 1 };
}
// src/routes/sum/+page.js
export async function load({ parent }) {
    const { c } = await fetchCFromThirdParty();
    const { a, b } = await parent();
    return { d: a + b + c };
}

The universal load function can get data from the parent server load function, but not vice versa.

`load` dependencies

Calling fetch(url) inside a load function registers url as a dependency. Sometimes we can get data not through fetch but generate it, get it from internal storage, etc. In that case, we need to define this dependency manually by calling depends:

// src/routes/+layout.js
export async function load({ depends }) {
    depends('data:now');
    return { now: Date.now() };
}

Invalidation

SvelteKit has a built-in invalidation mechanism (e.g., it reruns when path params are changed; this mechanism can be disabled). However, in some cases, you need to force it and handle it manually, for example, when you need to invalidate data from the parent's load function. This can be done using the invalidate function, which takes a URL and reruns any load functions that depend on it:

// src/routes/+page.svelte
<script>
    import { onMount } from 'svelte';
    import { invalidate } from '$app/navigation';

    export let data;

    onMount(() => {
        const interval = setInterval(() => {
            invalidate('/dynamic-data-source'); // or 'dep:foo' in case of manual deps
        }, 1000);

        return () => {
            clearInterval(interval);
        };
    });
</script>

If you need to invalidate based on some pattern, you can pass a callback argument instead of a plain string: invalidate(url => url.href.includes('foo')).
invalidateAll() can be used to rerun all load functions.
- invalidateAll reruns load functions without any URL dependencies, which invalidate(() => true) does not.

Headers and Cookies

Inside a load function (also in form actions, hooks, and API routes, which we'll learn about later), we have access to the setHeaders function:

export function load({ setHeaders }) {
    setHeaders({
        'Content-Type': 'text/plain'
    });
}

Cookies

setHeaders cannot be used with the Set-Cookie header. Instead, use cookies:

export function load({ cookies }) {
    const visited = cookies.get('visited');
  cookies.set('visited', 'true', { path: '/' }); // cookies.set(name, value, options)

    return {
        visited: visited === 'true'
    };
}

cookies.set(name, ...) causes a Set-Cookie header to be written and updates the internal state of cookies (using the cookie package under the hood).
It is strongly recommended to configure the path when setting a cookie since the default behavior of browsers is to set the cookie on the parent of the current path.

Shared Modules

If you need to share code across multiple places, the right place to keep it is the src/lib folder. You can access it via the $lib alias:

// src/lib/message.js
export const message = 'hello from $lib/message';

// src/routes/a/deeply/nested/route/+page.svelte
<script>
    import { message } from '$lib/message.js';
</script>

<p>{message}</p>

That's all for now! I hope you've enjoyed and felt the real power and potential that is baked into SvelteKit. In the next chapter, we will overview the rest of the toolset, such as hooks, page and link tuning.

See you soon, take care, and go Svelte!

Resources

SvelteKit tutorial | Introduction, Routing, Loading data, Headers and cookies, Shared modules
SvelteKit tutorial | Advanced routing, Advanced Loading
SvelteKit Docs | Advanced Layouts
Svelte Docs | Loading data

Svelte journey | Context API, Special Elements, Modularity, Debug

Denys Sych — Sat, 30 Dec 2023 15:17:41 +0000

Welcome,

today on our plate are as many tasty topics as before in previous articles. We'll cover contexts that allow us to set up component communication in a way that differs from props and event dispatching, special Svelte elements that enable us to handle some cases that are not achievable with other tooling. Then, we'll move to modules in Svelte and wrap up with a couple of words about debugging.

Context

Similar to React’s Context concept. In a nutshell: can be used for component communication omitting props & events.

setContext and getContext must be called during component initialization;
Context can include anything, including stores, functions, objects, etc.

<!-- Parent.svelte -->
<script>
    import { setContext } from 'svelte';
    setContext('canvas', {
        addItem
    });

    function addItem(fn) {...}
</script>
// ...

<!-- Child.svelte -->
<script>
    import { getContext } from 'svelte';
    // ...
    getContext('canvas').addItem(draw);
    function draw(ctx) {...};
</script>
// ...

Example with a store:

setContext('my-context', {
    count: writable(0)
});
const { count } = getContext('my-context')
$: console.log({ count: $count });

Special elements — built-in Svelte utility elements

svelte:self

<svelte:self {...props} /> — render component inside itself recursively (e.g., useful for a folder tree view).

svelte:component

<svelte:component this={selected.component}/> — you can render a component that you store in some variable.

When a property changes, the component is destroyed and recreated;
Can be falsy value → in that case, no error is thrown & nothing is rendered.

Similar behavior in React:

import { FancyButton, UglyBanner } from 'my-pocket';

function Container() {
    const { isBelovedClient } = useClientService();
    const Component = isBelovedClient ? FancyButton : UglyBanner;

    return <Component />;
}

In Svelte:

<script>
    import FancyButton from './FancyButton.svelte';
    import UglyBanner from './GreeUglyBannernThing.svelte';
    import isBelovedClient from './client-service.js';

    const targetComponent = isBelovedClient ? FancyButton : UglyBanner;
</script>
<svelte:component this={targetComponent}/>

svelte:element

Pretty much the same as <svelte:component /> but for basic HTML elements, not Svelte components.

The only supported binding is bind:this (no bind:value. Why: Svelte binds at build time);
Runtime error in case some children inside a void element (like <br />).

<svelte:element this={'div'}>
    I'm a  div
</svelte:element>

svelte:window

Interact with the window object. Supports bindings and handlers assignment.

<svelte:window on:keydown={handleKeydown} bind:scrollY={y} />

Bind props (All except scrollX and scrollY are readonly):

innerWidth;
innerHeight;
outerWidth;
outerHeight;
scrollX;
scrollY;
online — an alias for window.navigator.onLine.

svelte:body

svelte:body is like svelte:window but for document.body. E.g., on:mouseenter and on:mouseleave are not available in window but in document.body.

svelte:document

Allows you to listen for events that fire on document. E.g., selectionchange.

svelte:head

Allows you to insert elements inside the <head> of the document.

<!-- App.svelte -->
<svelte:head>
    <link rel="stylesheet" href="/stylesheets/{selected}.css" />
</svelte:head>

In SSR mode contents of <svelte:head> are returned separately from the rest of HTML.

svelte:options

To configure compiler options. There are a lot, a full list is better to check in the documentation.

Can be configured per component.

Example, telling the compiler that the component works with immutable data (by default Svelte works with mutable):

<svelte:options immutable />

<script>...</script>
...

svelte:fragment

Similar to React.Fragment. When you need to group several elements/components without a container DOM element.

Can be used with slot

<svelte:fragment slot="game">
    <button />
    <input />
</svelte:fragment>

Modularity

Run module code once

<script context="module"> — makes code run once, when the module first evaluates, not when the component initializes. You can have several <script /> tags per file, so it is possible to have default behavior as well:

<script context="module"> //
    let current;
</script>

<script>
    export let title;
    //...
</script>

It gives you the ability to keep persistent state, have singletons, etc.

Imports & Exports

Anything exported from a context="module" script block becomes an export from the module itself.

No default export for the module, because the component itself is the default export.

// Player.svelte -----------------------------------------------------
<script context="module">
    let current;
    export const stopAll = () => current?.pause();
</script>
// ...
// App.svelte --------------------------------------------------------
<script>
    import AudioPlayer, { stopAll } from './AudioPlayer.svelte';
</script>
// ...

You may remember also that if you do export from a regular <script /> it is also possible to access exported parts together with bind:this mechanism (bind:this section). The difference is that with context="module" you can do a particular import, and this code is not about a component instance but about a module, as it was mentioned before.

Debug

Old plain console.log(...) in the markup section or special {@debug ...} tag with a comma-separated list of values you want to inspect.

<script>
    let name = 'Ada';
</script>
<input bind:value={user.firstname} />

{@debug user}

<h1>Hello {user.firstname}!</h1>

@debug with devtools opened also stops execution, shows a stack trace and other debug regular things.

I'm happy to share with you that this article is a finishing point of our Svelte’s overview! This article wraps up the part about Svelte as a UI library / component framework for building robust interfaces.

But it is not the finish line in our journey; it is just another turn over! In the next article, we’ll start to explore SvelteKit framework — framework / metaframework, that provides surrounding tooling for building full-steam applications.

See you in the next articles,

take care, go Svelte!

Resources

Svelte Tutorial | Context API, Special Elements, Module context, Miscellaneous

Svelte journey | Actions, Advanced Bindings, Classes & Styles, Slots

Denys Sych — Wed, 27 Dec 2023 17:35:26 +0000

Welcome,

In the previous part, we reviewed Svelte’s capabilities for smooth visual effects, and today we’re going to explore actions, some more bindings, styles and content projection.

Actions — element-level lifecycle functions

It feels like behavior directives in Angular or useRef + DOM manipulations in React.

Useful for things like:

interfacing with third-party libraries;
various DOM operations.

// actions.js 
/*
 * node - target DOM Node
 * options - optional custom params. Useful for 3rd party prop. pass 
*/
export function trapFocus(node, options) {
    function handleKeydown(event) { ... }
  ...
    node.addEventListener('keydown', handleKeydown);
    return {
        destroy() { // clean up on node unmount
            node.removeEventListener('keydown', handleKeydown);
        }
    };
}

// App.svelte
...
<div class="menu" use:trapFocus={{anyParameters: true, youWantToPass: value}}>...</div>

Advanced bindings

Just a reminder, it is about bi-directional value synchronization. Advanced bindings are the same bindings by nature as “basic” ones, just use-cases are not as common as the regular value attribute or component’s input bindings.

// 'contenteditable' elements support 'textContent' and 'innerHTML' bindings
<div bind:innerHTML={html} contenteditable /> 

// bind:checked, bind:value works with #loop. But this mutates the array! 
{#each todos as todo}
    <li class:done={todo.done}>
        <input type="checkbox"  bind:checked={todo.done} />
        <input type="text" bind:value={todo.text}   />
    </li>
{/each}

// <audio> and <video> (media) el-s support:
<audio
        {src}
        bind:currentTime={time}
        bind:duration
        bind:paused
        bind:buffered
        bind:seeking
        bind:ended
        bind:readyState
        bind:playbackRate
        bind:volume
        bind:muted
    /> // + <video /> has bind:videoWidth and bind:videoHeight

// Every block-level element has clientWidth, clientHeight, offsetWidth, and offsetHeight
<div bind:clientWidth={w} bind:clientHeight={h}>
    <span style="font-size: {size}px" contenteditable>{text}</span>
    <span class="size">{w} x {h}px</span>
</div>

// bind:this is like useRef - gives us a reference to the element (or component instance)
// Stays 'undefined' until mounted
<canvas bind:this={canvasRef}   width={32} height={32} />
<CanvasWrapper bind:this={canvas} size={size} />

// Component input bindings work the same as other bindings. Not recommended as data flow becomes implicit
<Keypad bind:value={pin} on:submit={handleSubmit} />

Bindings in a loop mutate the array

<input> elements will mutate the array. If you prefer to work with immutable data, you should avoid these bindings and use event handlers instead.

{#each todos as todo}
        <input type="text" value={todo.text} on:change={(e) => updateTodo(e, todo.id)}  />
{/each}

Block-level bindings (clientWidth, clientHeight, offsetWidth, and offsetHeight) limitations

These bindings are readonly (if you change the bounded value it makes no effect);
display: inline elements cannot be measured;
elements that can't contain other elements (such as <canvas>) cannot be measured.

`bind:this`

Works both for regular DOM elements and Svelte components (binds to an instance). It feels like useImperativeHandle with forwardRef in React. To define what can be used outside, mark it with export keyword:

// CanvasWrapper.svelte --------------------------------------------
<script>
    export const clear = () => ...;
</script>

// App.svelte --------------------------------------------
<script>
    let canvas;
    let size = 10;
</script>
...
<CanvasWrapper bind:this={canvas} size={size} />
<button on:click={() => canvas.clear()}>reset</button>

Classes and styles

Work like any other attribute.

// Class attribute
<span class="card {isReady ? 'ready foo' : 'bar baz'}" /> // you can provide a string
<span class:flipped={isItemFlipped} /> // or, shorter, class:<name>={boolean}
<span class:flipped /> or, even shorter, when the class name meets the variable name

// Style attribute
<span style="transform: {flipped ? 'rotateY(0)' : ''}; --bg-1: palegoldenrod; --bg-2: black; --bg-3: goldenrod" />
// Or with style directive
<span 
    style:transform={flipped ? 'rotateY(0)' : ''}
    style:--bg-1="palegoldenrod"
    style:--bg-2="black"
    style:--bg-3="goldenrod" />

Child component style override

The first option: :global modifier. ❗Bad practice approach — you gain a lot of power but it violates component approach basics. Use wisely.

Better is when the component decides which part of its styling is modifiable. For that purpose in Svelte is the mechanism that is about providing custom CSS variables:

// Box.svelte
<div class="box" />

<style>
    .box {
        background-color: var(--color, black); // --color is provided or defaults to "black"
    }
</style>

// App.svelte
<script>
    import Box from './Box.svelte';
</script>

<div class="boxes">
    <Box --color="red" /> // --color is passed to <Box />
</div>

Component composition — `<slot />`

In other words, where the component’s children should settle.

// Default (single) slot - Card.svelte
<div class="card">
    <slot />
</div>
// Single slot - App.svelte
<Card>
    <span>Patrick BATEMAN</span> // Goes instead of <slot /> inside Card
    <span>Head of HR</span> // Goes instead of <slot /> inside Card as well
</Card>

Named slots

Pretty much the same as regular ones but if the slot is named, it goes to a relative place.


// Named slots - Card.svelte
<div class="card">
    <header>
        <slot name="company" />
    </header>
    <slot />
    <footer>
        <slot name="address" />
    </footer>
</div>
//Named slots - App.svelte
<span>Patrick BATEMAN</span>
<span>Head of HR</span>
<span slot="company">Mental health coaching</span>
<span slot="address">358 Exchange Place, New York </span>

Slot fallback

If nothing is passed to a slot, it displays content inside.


// Slot fallback
<div class="card">
    <header>
        <slot name="company">(Company) Fallback for named slot</slot>
    </header>
    <slot>Fallback for default slot</slot>
</div>

Slot props

To pass data back to the slotted content.

// FilterableList.svelte
<script>
    export let data;
  ...
</script>
<div class="list">
    {#each data.filter(matches) as item}
        <slot {item} /> // passing required prop to the slotted content
    {/each>
</div>
...

//App.svelte
<FilterableList
    data={colors}
    field="name"
    let:item={row} // <- it tells that "item" inside iterable should be passed as "row" to this slotted content
>
    <div class="row">
        <span class="color" style="background-color: {row.hex}" />
        <span class="name">{row.name}</span>
    </div>
</FilterableList>

For named slots, it is pretty much the same. You just need to put let: inside a slot:

<!-- FancyList.svelte -->
<ul>
    {#each items as item}
        <li class="fancy">
            <slot name="item" {item} />
        </li>
    {/each}
</ul>

<slot name="footer" />

<!-- App.svelte -->
<FancyList {items}>
    <div slot="item" let:item>{item.text}</div>
    <p slot="footer">Copyright (c) 2019 Svelte Industries</p>
</FancyList>

Check slot’s presence / conditional slots

You can check their presence via $$slots :

{#if $$slots.header}
    <div class="header">
        <slot name="header"/>
    </div>
{/if}

See you in the next article,

take care, go Svelte!

Resources

Svelte Tutorial | Motions, Transitions, Animations
Svelte docs | Slots

Svelte journey | Motion, Transitions, Animations

Denys Sych — Tue, 26 Dec 2023 07:30:18 +0000

Since this chapter we shift to more in-depth Svelte themes. In this part we’ll cover visual tooling that comes from Svelte. It is really great that you can have beauty things right out of the box, without reinventing the wheel and with no need for extra tooling.

Motion

Functions that produce store-like value that changes in a way to have a smooth & good looking behaviour. Basically, it calculates all required values and emits them in the required interval of time (it has something more under the hood, this description is rather just to catch the idea).

Tweened

<script>
    import { tweened } from 'svelte/motion';
    import { cubicOut } from 'svelte/easing';


    const progress = tweened(0, { // second param is optional 
        duration: 400,
        easing: cubicOut,
        delay: ..., // ms
        easing: ..., // p => t
        duration: ..., // (from, to) => milliseconds
        interpolate: ..., // (from, to) => t => value
    });
</script>
...
progress.set(50); // or progress.update(v => v + 1);
...
<input bind:value={progress} type="range"   />

Spring

The spring function is an alternative to tweened that often works better for values that are frequently changing.

<script>
    import { spring } from 'svelte/motion';
    let coords = spring({ x: 50, y: 50 }, {
        stiffness: 0.1,
        damping: 0.25
    });
</script>
...
<input bind:value={coords.stiffness} /> // damping/stiffness update is possible later
<circle cx={$coords.x} cy={$coords.y} /> // operate then as with regular store

Transition

Differs from motion as motion it rather about target value, but transition is rather about target DOM Object.

<script>
    import { fade, fly } from 'svelte/transition';
    let visible = true;
</script>

<input type="checkbox" bind:checked={visible} /> // <p /> will fade in/out
{#if visible} 
 <p transition:fade>Fades in and out</p>
 <p transition:fly={{ y: 200, duration: 2000 }}>Params are optional</>
 <p in:fly={{ y: 200, duration: 2000 }} out:fade>Flies in, fades out</p> // diferent in, out
{/if}
...

`If` block + transition = ❤️

Remember times when you hide something with your framework via if-else templating and this block just disappears instantly as a ninja because it literally is cut from DOM? Forget about this in Svelte (at least, in this case) — it takes care and hides/shows the element in transitioned, expected manner. If there are several blocks, you may need to use global transition that is described next.

Global transitions — transition for any element

Add |global when you need to apply transition when any block containing the transitions is added or removed. E.g. toggling the visibility of the entire list does not apply transitions to individual list elements.

{#if showItems}
    {#each items.slice(0, i) as item}
        <div transition:slide|global> // when showItems changes, global still makes transition to work as expected
            {item}
        </div>
    {/each}
{/if}

`{#key}` Key blocks — recreate children’s DOM when an expression changes

When you need to have transition not only when element enters/leaves the DOM, but when some value changes.

{#key i} // when I changes, inside stuff recreates. As a result in: transition is shown when fresh 'i' comes
    <p in:typewriter={{ speed: 10 }}>
        {messages[i] || ''}
    </p>
{/key}

Transition events

Usage as regular DOM event:

<div
    transition:fly={{ y: 200, duration: 2000 }}
    on:introstart={() => status = 'intro started'}
    on:outrostart={() => status = 'outro started'}
    on:introend={() => status = 'intro ended'}
    on:outroend={() => status = 'outro ended'}
/>

Custom transitions — write own functions if default set is not enough

To have something custom you need to build a function that meets transition functions contract. Attaching here samples from official tutorial:


<script>
    import { fade } from 'svelte/transition';
    import { elasticOut } from 'svelte/easing';

    let visible = true;

  // Custom CSS (css property is returned)
    function spin(node, { duration }) {
        return {
            duration,
            css: (t) => {
                const eased = elasticOut(t);

                return `
                    transform: scale(${eased}) rotate(${eased * 1080}deg);
                    color: hsl(
                        ${Math.trunc(t * 360)},
                        ${Math.min(100, 1000 * (1 - t))}%,
                        ${Math.min(50, 500 * (1 - t))}%
                    );`;
            }
        };
    }
// Custom JS (tick property is returned)
function typewriter(node, { speed = 1 }) {
    const text = node.textContent;
    const duration = text.length / (speed * 0.01);

    return {
        duration,
        tick: (t) => {
            const i = Math.trunc(text.length * t);
            node.textContent = text.slice(0, i);
        }
    };
</script>
...
<div out:fade   ... />
<p transition:typewriter ... />

Deferred transitions — when you need a smooth transit between different host components

This feature looks really cool. DOM elements literally fly out from on parent component into another. To achieve it you need to define a crossfade function and then assign its output to target object.

The crossfade function creates a pair of transitions called send and receive. Then, its output is assigned to desired markup element that is expected to be moved across:

export const [send, receive] = crossfade({...});
...
<li
    class:done
    in:receive={{ key: todo.id }}
    out:send={{ key: todo.id }}
>

When an element is 'sent', it looks for a corresponding element being 'received', and generates a transition that transforms the element to its counterpart's position and fades it out. When an element is 'received', the reverse happens. If there is no counterpart, the fallback transition is used.

Animation

<script>
    import { flip } from 'svelte/animate';
    ...
</script>
...
<li
    ...
    animate:flip // animate:flip={{ duration: 200 }} | animate:flip={{ duration: d => millis }}
>

We’ve covered the main topics regarding the theme, still it is rather an overview what exists in the toolbox and to master this properly will require some extra efforts.

Take care, go Svelte!

Resources

Svelte Tutorial | Motions, Transitions, Animations
Svelte transition docs

Svelte journey | Bindings, Lifecycles, Stores

Denys Sych — Sat, 23 Dec 2023 10:39:02 +0000

Basics: Bindings, Lifecycles, Stores

Welcome here,

This article marks the finishing point in covering the most basic Svelte stuff. Recently, we found out about props, template directives, events, and today we are going to review bindings, lifecycles, and stores.

Bindings

What is this

Two-way binding like <my-input [(value)]=”value”></my-input> in Angular or <Input value={name} onChange={setName} /> in React:

<script>
    let name = 'world';
</script>
<input bind:value={name} />
<h1>Hello {name}!</h1>

Automatically converts value type

In DOM everything is a string, but Svelte converts value’s type according to type attribute:

<input type="number" bind:value={a} min="0" max="10" /> // number
<input type="range" bind:value={a} min="0" max="10" /> //number
<input type="checkbox" bind:checked={yes} /> // boolean
<select bind:value={selected}   on:change={() => answer = ''} /> // object
<textarea bind:value></textarea> // string, shorthand form
<textarea bind:value={value}></textarea> // string, full form

Select initial value

Default value for selected in <select bind:value={selected}... /> is first entry. Still, while bindings are initialised, selected remains undefined, be careful, use Elvis ?: selected?.id.

Enabling `<select />` multi select ability

<select multiple bind:value={flavours}>
  {#each ['vanilla', 'coffee'] as flavour}
        <option>{flavour}</option>
    {/each}
</select>

Group inputs (radio groups, checkbox groups)

{#each ['vanilla', 'coffee'] as flavour}
    <label>
        <input
            type="checkbox"
            name="flavours"
            value={flavour}
            bind:group={flavours} // it is an array
        />

        {flavour}
    </label>
{/each}

Lifecycle

onMount does not run inside a server-side component;
onMount must be called during the component's initialisation, but doesn't need to live inside the component.

<script>
    import { onMount, onDestroy, beforeUpdate, afterUpdate, tick } from 'svelte';
    import { paint } from './gradient.js';

    ...

    // After the component is first rendered to the DOM
    onMount(() => {
        doThings();
        return () => cleanup();
    });
    // Immediately before the DOM is updated. Before mount, too.
    beforeUpdate(() => {
        if (thing) {
            process(thing);
        }
    });
        // Once the DOM is in sync with your data
    afterUpdate(() => {
        if (thing) {
            process(thing);
        }
    });
    // tick() usage example: Await in-progress DOM changes
    async function handleSelection() {
        someStateUpdates();
        await tick();
        performSomeOperationThatRequiresUpdatedDOM();
    }
    // On destroy
    onDestroy(anotherCleanup);
});
</script>

Also, lifecycle functions can be called not only in the root ... but also from some kind of callback. Also, they can be called multiple times. For example, the next code sample is absolutely valid:

<script>
    let items = new Set();

    onMount(() => {
        // ...
    });

    function addItem(fn) {
        onMount(() => {
            items.add(fn);
            return () => items.delete(fn);
        });

        afterUpdate(async () => {
            // ...
            await tick();
            // ...
        });
    }
    //...
</script>

Component state update ≠ update the DOM immediately

Instead, it waits until the next microtask to see if there are any other changes that need to be applied, including in other components (batching and optimization).

To await updated DOM in the same function execution, we can use await tick(), which resolves when pending DOM updates are completed.

Stores

Dealing with data management, avoid prop drilling.

// stores.js ------------------------------------------------------------
import { writable } from 'svelte/store';
export const count = writable(0);
// Demo.svelte ------------------------------------------------------------
<script>
    import { count } from './stores.js';

        let count_value;

    const unsubscribe = count.subscribe((value) => { // manual subscription (better to use auto-sub $count)
        count_value = value;
    });
    onDestroy(unsubscribe); // requires unsubscription on destroy

    const reset = () => count.set(0);
  const increment = () => count.update((n) => n + 1);

    $: console.log("count is " + $count); // Auto-sub in script
</script>
...
<h1>The count is {count_value}</h1>
<h1>The count is {$count}</h1> // Auto-sub in markup

`$value` Auto-subscription

Works only with store variables that are declared (or imported) at the top-level scope of a component;
$ is reserved prefix and it always assumed to refer to a store value.

Writable, Readable, Derived stores

All stores are consumed in the same manner (with different capabilities).

Writable as in the example — you can both read and write inside consumer code. const count = writable(initialValue?);
Readable — readonly in consumers. const value = readable(initialValue?, startFn, endFn) where:
- initialValue - initial value, can be null or undefined;
- startFn - is called when first subscribe happens (Like initialisation of Hot Observable in RxJS);
- endFn - is called on last unsubscribe.
Derived — on one hand, like selectors in Redux. On the other hand, can set value to itself instead of returning it (useful for async derive). const doubled = derived(stores,deriveFn, initialValue?)

Derived store specifics

Set value

Derived stores can set value? This part was not fully clear at first, but after some exploration I’ve figured out that it is about that you can just derive in async way: instead of instant convert you may hit an API or perform any other async. operation. In that case you can’t return promise or callback to tell that it is async. But what you can do is a call set or update in your’s async operation callback to emit the desired output.

import { derived } from 'svelte/store';

const delayed = derived(
    a,
    ($a, set) => {
        setTimeout(() => set($a), 1000);
    },
    2000
);

const delayedIncrement = derived(a, ($a, set, update) => {
    set($a);
    setTimeout(() => update((x) => x + 1), 1000);
    // every time $a produces a value, this produces two
    // values, $a immediately and then $a + 1 a second later
});

Can return function from deriveFn

It will be called when a) the callback runs again, or b) the last subscriber unsubscribes.

import { derived } from 'svelte/store';
const tick = derived(
    frequency,
    ($frequency, set) => {
        const interval = setInterval(() => {
            set(Date.now());
        }, 1000 / $frequency);
        return () => {
            clearInterval(interval);
        };
    },
    2000
);

Custom stores

Custom store is a conventional name in Svelte for such kind of facade that is the code snippet below. Nothing special.

function createCount() {
    const { subscribe, set, update } = writable(0);

    return {
        subscribe,
        increment: () => update((n) => n + 1),
        decrement: () => update((n) => n - 1),
        reset: () => set(0)
    };
}

Store bindings

Actual for writable stores. Usage is the same as with local variables, just prefix with $:

export const name = writable('world');
...
<input bind:value={$name}>

<button on:click={() => $name += '!'}> // same as: name.set($name + '!')
    Add exclamation mark!
</button>

That's all for today, take care, go Svelte!

Resources

Svelte Tutorial
Svelte Documentation | Stores

Svelte journey | Props, Template Directives, Events

Denys Sych — Fri, 22 Dec 2023 19:33:52 +0000

Welcome,
this is the second part of our amazing Svelte journey. Previously, we’ve learned about the basics, template and reactivity. Today, we'll delve into Props, Template Directives, and Events. So, let’s start.

Props

⚠️ `export` keyword is not regular JS `export`

export marks that a variable is an external, input property.

<script>
    export let foo; // 'export' means input prop
    export let marko = 'Polo'; //  input prop with default value
</script>

{…spread} props

Pretty same as in React:

<PackageInfo
    name={pkg.name}
    speed={pkg.speed}
    version={pkg.version}
    website={pkg.website}
/>

<PackageInfo {...pkg} />

$$props — last resort stuff 🚩

Is needed for reference all props (including also properties, that were not mentioned as inputs (export let <prop name>) for the component).

Feels like (…props: any[]) or JS function’s arguments;
$$restProps allows to do the same but only for props, that were not mentioned as inputs;
Not recommended, difficult for Svelte to optimise.

Template Directives

// Conditional rendering
{#if count > 10}
    <p>{count} is greater than 10</p>
{:else if count < 5}
    <p>{count} is less than 5</p>
{:else}
    <p>{count} is between 5 and 10</p>
{/if}
// Iterables (any generic iterables) rendering
{#each colors as color, i (color)} // ", i" is optional; (*) is key, also optional
    <span>{color}, idx: {i}</span>
{/each}

`Key` for lists rendering

similar to other libs/frameworks, optimises DOM updates;
any object can be key, but string or number is safer. So keep it safe.

// Key usage samples
{#each things as thing, i (thing.id)}
    <Thing name={thing.name + " - " + i}  />
{/each}
{#each things as thing, i (i)}
    <Thing name={thing.name + " - " + i}  />
{/each}

`await` blocks for async operations 🍭

Kinda async pipe from Angular or useQuery from tanstack's library
Only the most recent promise is considered — new value comes into variable and cancels previous pending state if some.

// Basic async stuff
{#await promise}
    <p>...waiting</p>
{:then number}
    <p>The number is {number}</p>
{:catch error}
    <p style="color: red">{error.message}</p>
{/await}

// if you're sure there are no rejects
{#await promise then number}
    <p>The number is {number}</p>
{/await}

Events

<script>
    let m = { x: 0, y: 0 };

    function handleMove(event) {
        m.x = event.clientX;
        m.y = event.clientY;
    }
</script>

<div
    on:pointermove={handleMove}  // Handler fn.
    on:click={(e) => {           // Inline handler
        console.log(m, e.target);
    }}
>
    The pointer is at {m.x} x {m.y}
</div>

`Modifiers` for event handlers 🍰

Pipelike handy notation to apply modifiers:

<button on:click|once={() => alert('clicked')}>
    Click me
</button>
<button on:click|once|self|capture={() => alert('you can chain them!')}>
    Click me
</button>

Available modifiers:

preventDefault;
stopPropagation;
passive — about scrolling. Svelte handles it automatically;
nonpassive — explicitly set passive: falsecapture;
once;
self — only trigger handler if event.target is the element itself;
trusted — only trigger handler if event.isTrusted is true, meaning it is a action performed by human (click) rather than by code.

Component events

You need to:

have a name for an event;
dispatch this event via special dispatcher service, that is provided by svelte;
assign to events and handle them.

Here is a simple example:

// Inner.svelte --------------------------------------------------------------
<script>
    import { createEventDispatcher } from 'svelte'; // the service

    const dispatch = createEventDispatcher(); // we created dispatcher

    function doSomething() { 
        dispatch('somethingHappened', { // dispatch 'somethingHappened' event
            action: 'You did it!'
        });
    }
</script>

<button on:click={doSomething}> // click will trigger event dispatch
    Do it.
</button>
// Outer.svelte --------------------------------------------------------------
...
<Inner on:somethingHappened={handleEvent} /> // listen to an event
...

And this example is more broad, it depicts how you can forward dispatches and how to handle not only component events, but also DOM events:

// App.svelte ------------------------------------------------------------
<script>
    import Outer from './Outer.svelte';
    import CustomButton from './CustomButton.svelte';

    function handleMessage(event) {
        alert(event.detail.action);
    }

    function handleClick(event) {
        alert("Polo!");
    }

</script>
<Outer on:somethingHappened={handleMessage} />

<CustomButton on:click={handleClick} />
// Outer.svelte ------------------------------------------------------------
<script>
    import Inner from './Inner.svelte';
    import { createEventDispatcher } from 'svelte';

    const dispatch = createEventDispatcher();

    function forward(e) {
        dispatch('somethingHappened', e.detail);
    }
</script>

<Inner on:somethingHappened={forward} />
// Inner.svelte ------------------------------------------------------------
<script>
    import { createEventDispatcher } from 'svelte';

    const dispatch = createEventDispatcher();

    function doSomething() {
        dispatch('somethingHappened', {
            action: 'And something happened!'
        });
    }
</script>

<button on:click={doSomething}>
    Time has come
</button>
// CustomButton.svelte -------------------------------------------------------
<script>
    import { createEventDispatcher } from 'svelte';
    const dispatch = createEventDispatcher();

    function forwardClick(e) {
        dispatch('click', e)
    }
</script>
<button on:click={forwardClick}>
    Marko
</button>

<style>
    button {
            background: navajowhite;
            padding: 4px 8px;
    }
</style>

createEventDispatcher must be called at the initialisation;
component events don't bubble — you need to forward them;
DOM event forwarding — the same as component’s events.

Amazing REPL, Amazing CLI

The code snippets quickly outgrew the tutorial's IDE, prompting me to seek alternatives. I turned to the Svelte REPL, an online environment that seemed perfect and even offered PWA installation. However, my intention was to experiment without registration, which unfortunately wasn't allowed.

Undeterred, I chose to download it locally using npm create svelte@latest my-app, and the experience was remarkably convenient 🏅. However, my initial excitement dwindled when npm install raised concerns about broken dependencies. While forcing it was an option, opting for stability with a non-beta version proved to be the solution. It serves as a valuable reminder that only reliable components should make their way into production.

In the end, everything is running smoothly.

Take care, go Svelte!

Resources

Svelte Tutorial

Svelte journey | Templating, Reactivity

Denys Sych — Fri, 22 Dec 2023 08:58:32 +0000

Hello!

Svelte has been in my vision scope for quite some time, but it wasn't until today that I actually started exploring it. Finally, I decided to dig it further, triggered by another encounter with yet another post titled "Svelte changed my life". I bet a lot of people heard about it but didn’t start for some reason. Well, this article may be the one!

I may draw parallels to well-known approaches/tooling (mostly React or Angular) when applicable and interject with my own commentary.

Of course, I highly recommend referring to the official tutorial, it is great. However, my aim is to distill the most relevant information and incorporate some thoughts that crossed my mind, you may find this also helpful.

In the context of this series, our goal is to grasp the fundamentals of Svelte as a UI library and SvelteKit as a comprehensive toolkit that equips us with a mature set of tools to construct outstanding applications.

We'll commence with the Basics and delve into Reactivity in this article. You might have already heard about reactivity in Svelte, and it's truly amazing. Still, Svelte team prepares some updates regarding that (Runes, signals).

In this chapter, we embark on our journey together. So, let's delve in.

Templating and basic stuff

<script>
    import Nested from './Nested.svelte';
  let count = 0;

    function increment() {
        count += 1;
    }
</script>

<p>This is a paragraph.</p>

<Nested />

<button on:click={increment}>
    Clicked {count}
    {count === 1 ? 'time' : 'times'}
</button>

<style>
    p {
        color: goldenrod;
        font-family: 'Comic Sans MS', cursive;
        font-size: 2em;
    }
</style>

It looks pretty much the same as the well-known JSX, so don't expect anything too spicy at this point.

However, there are some perks that I would like to outline:

Shorthand attributes

<img {src} alt="{name} dances." /> — no need for src={src}, just {src} is enough.

Code placement

Styles, code, and template in a single file. Code should be wrapped in <script />, and styles in <style />.

Handlers notation

<button on:click={increment}> — not onClick.

Plain string HTML embed

If you need to render HTML stored in a plain string, then use <p>{@html string}</p>. Keep in mind that there is no sanitization. Dangerous HTML stays dangerous 🔫.

Reactivity 💲

As mentioned at the beginning (and as everyone constantly emphasises), reactivity in Svelte is a pure gold. Still, some updates are coming in Svelte 5.

// Example of basic reactivity usage
<script>
  let count = 0;
  $: doubled = count * 2;                  // Kind of like a selector

  $: if (count >= 10) {                    // Kind of a Conditional Effect
    alert('Count is dangerously high!');
    count = 0;
  }

  $: console.log(`The count is ${count}`); // Kind of a one-line Effect

  function increment() {
    count += 1;
  }
</script>

<button on:click={increment}>
  Clicked {count} {count === 1 ? 'time' : 'times'}
</button>

<p>{count} doubled is {doubled}</p>

Crucial parts, in my opinion, are as follows:

$ Reactive declarations (something like selectors)

let count = 0;
$: doubled = count * 2; // This code `$: doubled = count * 2` re-runs whenever any of the referenced values change.

Why not use plain variables for the same purpose?
Variables (let, const) always keep the same initial constant values if you try to make them like $.

For example:

let a = 1;
let b = a * 2;
$: c = a * 2;
function foo() { a++ }

When foo is called: a and c changes, but b remains the same. You can do assignment of b inside the function to change it, but that is another story, which we’ll get to in a minute.

Calling order

Reactive declarations and statements run after other script code and before component markup is rendered.

$ Reactive statements (looks like effects)

Automatic calls happen when the dependency is updated, which feels really good.

// one liner
$: console.log(`The count is ${count}`);
// group multiple lines
$: {
  console.log(`The count is ${count}`);
  console.log(`This will also be logged whenever count changes`);
}
// with operator (if)
$: if (count >= 10) {
  alert('Count is dangerously high!');
  count = 0;
}

$ Reactive stuff and referential types

Mutations

push, splice, and similar mutation operations won't automatically cause updates. If you want to change something, then an assignment should happen.

// Ugly way
function addNumber() {
  numbers.push(numbers.length + 1);
  numbers = numbers; // Apply update via assignment
}
// [...pretty, way]
function addNumber() {
  numbers = [...numbers, numbers.length + 1];
}

Assignments to properties of arrays and objects, e.g., obj.foo += 1 or array[i] = x, work the same way as assignments to the values themselves. So, as with plain old assignment for let or const, values inside properties can be modified without reassignment.

<script>
  let foo = { bar: 2 };
  let oof = foo;

  function handleClick() {
    foo.bar = foo.bar + 1; // This will update {foo.bar}
    foo.bar = oof.bar + 1; // This will also update {foo.bar}
    // Uncomment next line to make {oof.bar} be updated
    // oof = oof;
  }
</script>

<button on:click={handleClick}>
  foo.bar: {foo.bar} | oof.bar: {oof.bar}
</button>

A simple rule of thumb: the name of the updated variable must appear on the left hand side of the assignment.

For example:

// Won't trigger reactivity on obj.foo.bar
// unless you follow it up with obj = obj.
const obj = { foo: { bar: 1 } };
const foo = obj.foo;
foo.bar = 2;

By the way, you may be in the same situation as me: when I came across this code sample in the tutorial, I interpreted it as something like this:

<script>
  const obj = { foo: { bar: 1 } };
  const foo = obj.foo;
  foo.bar = 2;

  $: pluckedBar = obj.foo.bar

  obj.foo.bar = 100; // This still triggers reactivity
</script>

{pluckedBar} // Shows 100, but I had a feeling that it should stay

After spending some time, I figured out that it is actually this:

<script>
  let obj = { foo: { bar: 1 } };
  let foo = obj.foo;
  $: pluckedBarBeforeReassign = foo.bar
  foo.bar = 2;
  $: pluckedBarAfterReassign = foo.bar

  function doit() {
    foo.bar = foo.bar + 1;
    /*
     * If commented, then {obj.foo.bar} in the template would never update.
     * The rest, {foo.bar} {pluckedBarBeforeReassign} {pluckedBarAfterReassign}
     * act as expected.
    */
    // obj = obj
  }
</script>

<button on:click={doit}>
  {obj.foo.bar} <!--This guy you should pay attention to-->
  {foo.bar}
  {pluckedBarBeforeReassign}
  {pluckedBarAfterReassign}
</button>

Summary

In this part, we've covered the basics of templating and reactivity. We've followed the Svelte official tutorial, so if you feel excited about Svelte and want to have a broader look, it is a great idea to visit their interactive tutorial. My goal here is to share with you the most crucial information with extended comments on tricky parts, and I hope that I've accomplished that at least to some extent.

Take care, go Svelte!

DEV Community: Denys Sych

Svelte journey | SvelteKit: Page options, Link Options, Environment variables

Page Options

Link (Route) Options

Preloading

Programmatic Preload

Other Options

Environment Variables Access — $env Module

Private Variables

Static vs Dynamic

Public Variables

Final words

Resources

Svelte journey | SvelteKit: Server-side, SvelteKit utility stores, Error handling, Hooks

Forms — server-side interaction without client-side JS execution

Named form actions

Markup-based validation

Server-side validation

Progressive enhancement use:enhance — SPA-like API interaction

Customised enhancing for optimistic updates, pending states, etc.

API Routes

Stores

Page

Navigating

Updated

Errors and Redirects

Hooks

handle hook

event object in server hooks

event.fetch extra functionality

handleFetch hook

handleError hook

reroute hook

Resources

Svelte 4 journey | SvelteKit: Introduction, Routing, Data Loading, Shared Modules

General Information

Routing

Route structuring | +page.svelte

Common layout | +layout.svelte

Route parameters

Optional parameters

Rest (any number of unknown) parameters

Param matchers — validate route parameter

Route groups — subset of routes without changing a route’s path

Breaking out of layouts — independent children layout

Data loading

Page data | +page.server.js

Layout data | +layout.server.js

Universal load functions — when data does not come directly from your server

Server load and universal load together = server → universal → page data

Access parent’s load result inside own load function

load dependencies

Invalidation

Headers and Cookies

Shared Modules

Resources

Svelte journey | Context API, Special Elements, Modularity, Debug

Context

Special elements — built-in Svelte utility elements

svelte:self

svelte:component

svelte:element

svelte:window

svelte:body

svelte:document

svelte:head

svelte:options

svelte:fragment

Modularity

Run module code once

Imports & Exports

Debug

Resources

Svelte journey | Actions, Advanced Bindings, Classes & Styles, Slots

Actions — element-level lifecycle functions

Advanced bindings

Bindings in a loop mutate the array

Block-level bindings (clientWidth, clientHeight, offsetWidth, and offsetHeight) limitations

bind:this

Classes and styles

Environment Variables Access — `$env` Module

Progressive enhancement `use:enhance` — SPA-like API interaction

`handle` hook

`event` object in server hooks

`event.fetch` extra functionality

`handleFetch` hook

`handleError` hook

`reroute` hook

Route structuring | `+page.svelte`

Common layout | `+layout.svelte`

Page data | `+page.server.js`

Layout data | `+layout.server.js`

Server `load` and universal `load` together = server → universal → page data

Access parent’s `load` result inside own `load` function

`load` dependencies

`bind:this`

Component composition — `<slot />`

`If` block + transition = ❤️

`{#key}` Key blocks — recreate children’s DOM when an expression changes

Enabling `<select />` multi select ability

`$value` Auto-subscription

⚠️ `export` keyword is not regular JS `export`

`Key` for lists rendering

`await` blocks for async operations 🍭

`Modifiers` for event handlers 🍰