DEV Community: Geoff Rich

Assorted Svelte demos: conditional wrappers, page transitions, actions

Geoff Rich — Fri, 08 Jul 2022 15:33:56 +0000

Over the past couple months I’ve been posting some Svelte demos to Twitter. I’ve been meaning to turn some of them into full blog posts, but I’ve been quite busy so that hasn’t happened yet.

Since Twitter is ephemeral, I wanted to write a quick post capturing these demos for future reference. No in-depth explanations here—I’ll be keeping it pretty short. However, some of these might be given a full write-up in the future.

Using svelte:element to create a reusable wrapper

Geoff Rich

@geoffrich_

With the release of svelte:element, you can now create a reusable Wrapper component that can conditionally wrap its children with any HTML tag!

You could make this component before, but would need to hard-code the wrapper tag.

17:35 PM - 13 May 2022

svelte:element was released in Svelte 3.47.0, which allows you to dynamically render a given HTML tag. See the official tutorial section for more details. I used it to create a custom <Wrapper> component that can conditionally wrap its children.

<script>
  export let tag = 'div';
  export let wrap = false;
</script>

{#if wrap}
<svelte:element this="{tag}" {...$$restProps}>
  <slot></slot>
</svelte:element>
{:else}
<slot></slot>
{/if}

And it can be used like so:

<Wrapper tag="details" {wrap}>
  <summary>Yar 🦜 🏴‍☠️</summary>
  <p>
    Prow scuttle parrel provost Sail ho shrouds spirits boom mizzenmast yardarm. Pinnace
    holystone mizzenmast quarter crow's nest nipperkin grog yardarm hempen halter furl.
    Swab barque interloper chantey doubloon starboard grog black jack gangway rutters.
  </p>
  <p>
    Deadlights jack lad schooner scallywag dance the hempen jig carouser broadside cable
    strike colors. Bring a spring upon her cable holystone blow the man down spanker
    Shiver me timbers to go on account lookout wherry doubloon chase. Belay yo-ho-ho
    keelhaul squiffy black spot yardarm spyglass sheet transom heave to.
  </p>
</Wrapper>

Without this component, you’d have to introduce some significant duplication.

{#if wrap}
<details>
  <summary>Yar 🦜 🏴‍☠️</summary>
  <p>
    Prow scuttle parrel provost Sail ho shrouds spirits boom mizzenmast yardarm. Pinnace
    holystone mizzenmast quarter crow's nest nipperkin grog yardarm hempen halter furl.
    Swab barque interloper chantey doubloon starboard grog black jack gangway rutters.
  </p>
</details>
{:else}
<summary>Yar 🦜 🏴‍☠️</summary>
<p>
  Prow scuttle parrel provost Sail ho shrouds spirits boom mizzenmast yardarm. Pinnace
  holystone mizzenmast quarter crow's nest nipperkin grog yardarm hempen halter furl. Swab
  barque interloper chantey doubloon starboard grog black jack gangway rutters.
</p>
{/if}

(For the purposes of this demo, I rendered a summary element even when there’s no details. This is not actually valid HTML — you’d probably want to swap it out for an h2 or something when there’s no details.)

There's a full demo in the REPL with some more examples.

Native page transitions in SvelteKit

Geoff Rich

@geoffrich_

Played around with the new web API for page transitions in SvelteKit and the results are pretty slick! Chrome Canary only (w/ a flag) for now.

This all works using SvelteKit's beforeNavigate/afterNavigate hooks in the top-level __layout + `document.createDocumentTransition`

19:28 PM - 09 Jun 2022

I took the experimental page transition API (a.k.a. shared element transitions) for a test drive with SvelteKit, and the result was pretty slick. You’ll need Chrome Canary with the chrome://flags/#document-transition flag enabled if you want to try this one out yourself — the original tweet has a video if you don’t want to jump through those hoops. There’s a live demo and a GitHub repo if you want to see how it was accomplished.

I was able to implement it using SvelteKit’s beforeNavigate and afterNavigate hooks in a top-level __layout. It started out as a port of the shared element transitions Codelab but I added some extra features:

transitions to and from the list page (the original only transitioned to the details page, not from it)
transitions when the browser back & forward buttons are clicked
respects reduced motion by not playing the transitions when requested

I came back to this recently and refactored it to use a custom navigation store that made the logic a lot easier to follow.

This one will likely get a full write-up sooner rather than later, since I’ll be presenting it at a meetup in a couple weeks.

Action to detect when focus leaves an element

Geoff Rich

@geoffrich_

Wrote a quick li'l Svelte action to detect when focus leaves an element (or its children). This lets me autoclose a menu when a user tabs out of it.

(video alt: a menu appears showing a list of links. I tab through the links and the menu closes when I tab away from the last one)

17:31 PM - 15 Jun 2022

I was working on accessibility improvements to the new learn.svelte.dev site and needed to automatically close a pop-up menu when a user tabbed out of it. Otherwise, the user’s focus would move behind the menu and they couldn’t see where they are on the page. I ended up implementing it as an action. Here’s what it looks like:

function handleFocusLeave(node, cb) {
  function handleFocusIn() {
    if (!node.contains(document.activeElement)) {
      cb();
    }
  }
  document.addEventListener('focusin', handleFocusIn);

  return {
    destroy: () => {
      document.removeEventListener('focusin', handleFocusIn);
    }
  };
}

To see it in action, see the demo in the Svelte REPL or interact with the tutorial menu on learn.svelte.dev.

This was inspired by a similar approach from Andy Bell in a tutorial on building a burger menu.

Recursive Svelte action

Geoff Rich

@geoffrich_

Normally, you apply Svelte actions to single HTML elements with. But what if you want to apply the same action to a root node and all of its children?

You could manually apply the action to each node, or you could write a higher-order action that recursively does this for you.

16:02 PM - 29 Jun 2022

Normally, you apply Svelte actions to single HTML elements with use:action. But what if you want to apply the same action to a root node and all of its children? You could manually apply the action to each node, or you could write a higher-order action that recursively does this for you. I was able to implement this using a single action and a MutationObserver to track updates. Here’s what it looks like:

function recurse(node, {action, params}) {
  const observed = new Map();
  const act = node => action(node, params);

  function filterForElements(arr) {
    return Array.from(arr).filter(x => x.nodeType === Node.ELEMENT_NODE);
  }

  const observer = new MutationObserver(function(mutations) {
    mutations.forEach(mutation => {
      handleAdditions(mutation.addedNodes);
      handleRemovals(mutation.removedNodes);
    });
  });

  function handleAdditions(addedNodes) {
    for (const node of filterForElements(addedNodes)) {
      const cleanup = act(node);
      observed.set(node, cleanup);
    }
  }

  function handleRemovals(removedNodes) {
    for (const node of filterForElements(removedNodes)) {
      const cleanup = observed.get(node);
      cleanup?.destroy?.();
      observed.delete(node);
    }
  }

  observer.observe(node, {childList: true, subtree: true});

  const nodes = [node];
  while (nodes.length > 0) {
    const next = nodes.pop();
    const cleanup = act(next);
    observed.set(next, cleanup);
    nodes.push(...next.children);
  }

  return {
    update: ({params: newParams}) => {
      params = newParams;
      for (const [key, value] of observed) {
        value?.update(params);
      }
    }
  };
}

See the Svelte REPL for an example of it in action. The demo is a little contrived — I’m still not entirely sure how this would be useful. I just thought it was a neat idea and had to get it out of my head.

Svelte quick tip: Style prop defaults

Geoff Rich — Thu, 28 Apr 2022 15:08:28 +0000

Svelte has a built-in solution for component theming using style props. So, you can use CSS custom properties in your component styles...

<p>
    I have something important to say.
</p>

<style>
    p {
        border: 2px solid var(--line-color);

        /* Decorative styles */
        padding: 1rem;
        max-width: 60ch;
    }

</style>

...and easily set them from outside the component using style props.

<TextBox --line-color="mediumspringgreen"></TextBox>

But what if you want your style to have a default value? The custom property var syntax takes a second argument that sets a fallback if the property is not defined. So, if you wanted the default border color to be darkred, you could do the following.

p {
  border: 2px solid var(--line-color, darkred);
}

However, this can get verbose if you want to use --line-color in multiple places, with the same fallback. If you want to update the default value, you have to do it multiple places!

p {
  border: 2px solid var(--line-color, darkred);
  text-decoration: underline wavy var(--line-color, darkred) 1px;
}

There’s two ways to refactor this to make it less verbose. First, you could introduce another custom property for the default value:

p {
  --line-color-default: darkred;
  border: 2px solid var(--line-color, var(--line-color-default));
  text-decoration: underline wavy var(--line-color, var(--line-color-default)) 1px;
}

This makes it so there’s one place to change the default value, but you still have to provide the second argument to var every time you reference --line-color.

Instead, my recommended approach would be to introduce another custom property that represents either line-color or the fallback.

p {
  --_line-color: var(--line-color, darkred);

  border: 2px solid var(--_line-color);
  text-decoration: underline wavy var(--_line-color) 1px;
}

So now you have two variables:

--line-color is the user-supplied theme value
--_line-color is what we use in our styles, and will either be the user-supplied value (if defined) or the default color

You can see this in action in this Svelte REPL.

You only need to introduce a variable like --_line-color if you plan on using the theme variable multiple places. Otherwise, it’s perfectly fine to set the fallback where you use the property, as in the first example.

The technique on display here is not unique to Svelte, and can be applied anywhere you use custom properties. However, it's of particular interest with Svelte, since custom properties are the recommended way of theming a component.

4 tips for cleaner Svelte components

Geoff Rich — Wed, 06 Apr 2022 16:17:26 +0000

I've helped a few devs at my company get started with Svelte, and I love seeing how easy it is for them to pick it up and start being productive. However, I've noticed a few areas where they write verbose code without realizing that Svelte has a cleaner way to do the same thing.

Drawing on that experience, I've collected four ways to write cleaner and Svelte-ier component code. I think these will be especially helpful if you're new to Svelte, though more experienced devs might learn something too.

Work with the component template, not against it

When people are new to Svelte (or front-end frameworks in general), sometimes I see them use querySelector in their component code like this:

<script>
  function handleSubmit() {
    const submitButton = document.querySelector('.submit-button');
    submitButton.disabled = true;
    submitButton.innerText = 'Submitting...';
  }
</script>

<button class="submit-button" on:click="{handleSubmit}">
  Submit
</button>

Does it work? Sure. Is it a good idea? Absolutely not.

I think this happens because devs see the script tag and assume they should treat it like an inline script in a regular HTML document. But the script block in Svelte isn't just a script tag—it's a script tag with superpowers. You aren't limited to how you would interact with elements in vanilla JS.

The benefit of using Svelte (and other modern frameworks) is that your template can be driven by your component state. Instead of manually querying for elements, you can instead express that logic directly in your template. Here's how I would rewrite the first example to consolidate the logic inside the template:

<script>
  let submitting = false;

  function handleSubmit() {
    submitting = true;
  }
</script>

<button on:click="{handleSubmit}" disabled="{submitting}">
  {submitting ? 'Submitting...' : 'Submit'}
</button>

This makes your components much easier to reason about. You can look at the template and understand all the different states a component can be in, instead of trying to track down all the places where you might be updating something in the template.

(In addition, by writing document.querySelector you could potentially retrieve an element in a completely different component than what you're working in. Sometimes that's what you want, but usually it's not.)

Because of this, it's a good rule of thumb to avoid using querySelector, querySelectorAll, or any imperative query methods in your Svelte component. This isn't to say that you should never use them. However, using a feature built-in to Svelte would often be a better solution:

If you're updating text or attributes of an element inside your component, you should express it in your component template instead of querying for the element.
If you need a reference to a particular DOM element in your component (which is especially common when integrating vanilla JS libraries), you should first try using bind:this or an action.

Only once you've considered and ruled out these methods should you reach for querySelector.

Two-way binding is awesome

If you come to Svelte from React, you might instinctively write your form inputs this way:

<script>
  let value = '';

  function handleInput(e) {
    value = e.target.value;
  }
</script>

<label for="name">Name</label>
<input id="name" type="text" value="{value}" on:input="{handleInput}" />

<p>
  The value is {value}
</p>

This works, but is considered by many Svelte devs to be too much boilerplate. In Svelte, you can remove a lot of this code by using bind:value.

<script>
  let value = '';
</script>

<label for="name">Name</label>
<input id="name" type="text" bind:value />

<p>
  The value is {value}
</p>

This can significantly reduce the amount of code you write, especially if you have a lot of form inputs. And less code means fewer bugs.

You can also use two-way binding with component props. You need to be more careful with this kind of binding, since overusing it can make it hard to understand where state is being changed in your application. This is especially true if you use two-way binding across multiple layers of components, since any component in that tree could change the state for every component that's bound to it. But for form elements (and components that wrap form elements), two-way binding is the right choice.

For another perspective on this, see "How Svelte Makes Two-Way Binding Safe” by Daniel Imfeld.

Scoped styles let you write slimmer styles

In Svelte, styles are automatically scoped. You can write styles in a component and be assured that they won't leak out and unexpectedly affect another part of the application.

If you're used to working in projects without component-scoped styles, you might be used to writing lengthy class names to ensure that they don't conflict with styles in another part of the application. But in Svelte, you don't need to worry about that!

It's perfectly okay to use shorter, more generic class names like “heading” or “wrapper” in your Svelte component, since you can be confident that those styles won't accidentally apply to an element somewhere else. You can even target HTML tag names like p and button safely, though whether you should do this depends on the component.

For example, in the following example, I don't need to add a class to the button and paragraph just to style them. Since I want to style all paragraphs and buttons in this component, I can just target p and button directly, and elements outside this component won't be affected.

<p>
    Katamari Damacy (lit. 'Clump Spirit') is a
    third-person puzzle-action video game developed
    and published by Namco for the PlayStation 2.
    It was released in Japan in March 2004 and in North
    America in September 2004.
</p>

<button>
    That's neat!
</button>

<style>
    p {
        border-bottom: 2px solid limegreen;
        padding: 10px;
    }

    button {
        color: hotpink;
        font-size: 20px;
        font-weight: bold;
        background-color: black;
    }
</style>

If you're interested in how this scoping works, I did a deep dive on how Svelte scopes styles last year.

Don't miss out on all of Svelte's syntax sugar

Svelte has a lot of built-in niceties to reduce boilerplate for common tasks. Here are some that you might have overlooked:

Instead of doing manual string interpolation to add and remove classes or set inline styles, you can use class: and style:.
Instead of setting up an input listener and keeping local state in sync, you can use bind:value. Similarly, instead of wiring up a change listener to a group of radio buttons, you can use bind:group.
Instead of writing the same expression multiple times inside an #each block, you can use @const
Instead of bind:this and onMount when you need a reference to a particular DOM node, you can use an action

Either option will functionally produce the same result, but the second involves less code and more readable components (especially if you can get rid of tricky string interpolation).

I recommend giving the Svelte docs a full read-through, especially if it's been a while since you went through the tutorial. You might not know what you're missing!

Wrapping up

It was fun to do a “quick hits” style of article for this. There's a few more tips I'm chewing over, so you might see a follow-up article at some point.

Thanks to everyone who responded to my “common Svelte antipatterns” thread on Twitter (that also somehow devolved into a 🐫 case vs. 🐍 case debate). Go check that out for some other folks' ideas on what makes for cleaner Svelte components!

Local constants in Svelte with the @const tag

Geoff Rich — Tue, 08 Mar 2022 16:41:07 +0000

Style directives weren't the only new feature introduced in Svelte 3.46! Let's take a look at the other recent addition to Svelte: the @const tag.

The problem

Let's say you're displaying a list of boxes and calculating their areas, and also want to apply some styling when the area is a certain amount. You might think of doing something like this:

<script>
  let boxes = [
    {width: 1, height: 2},
    {width: 5, height: 2.5},
    {width: 2, height: 4}
  ];
</script>

{#each boxes as box}
  <p class:big={box.width * box.height > 10}>
    {box.width} * {box.height} = {box.width * box.height}
  </p>
{/each}

<style>
  .big {
    font-size: 2rem;
  }
</style>

Note that we compute box.width * box.height twice — once to display it, and once in the class:big directive. Even though the value hasn't changed, the browser still has to compute it twice. While this isn't an issue with a simple calculation like this, it could impact performance if the calculation was more intensive. It also introduces duplication into the code. If you needed to use the area more times (e.g. to apply different CSS classes), it would further compound these issues.

(As an aside, this is only a problem because we're inside an #each block. If there was only a single box, we could compute the area once in the script block and be done with it.)

Before the const tag was introduced, there were a few ways to work around this issue. You could create a helper function to compute the value...

<script>
  let boxes = [
    {width: 1, height: 2},
    {width: 5, height: 2.5},
    {width: 2, height: 4}
  ];

  function area(box) {
    return box.width * box.height;
  }
</script>

{#each boxes as box}
  <p class:big={area(box) > 10}>
    {box.width} * {box.height} = {area(box)}
  </p>
{/each}

This reduces the duplication, but it will still perform the computation multiple times unless you implement some form of memoization. Again, this is likely not a concern for a simple calculation like area, but it would be for more expensive calculations.

You could also create a new array that pre-computes the property you want...

<script>
  let boxes = [
    {width: 1, height: 2},
    {width: 5, height: 2.5},
    {width: 2, height: 4}
  ];

  let mappedBoxes = boxes.map(b => {
    return {
      ...b,
      area: b.width * b.height
    };
  });
</script>

{#each mappedBoxes as box}
  <p class:big={box.area> 10 }>
    {box.width} * {box.height} = {box.area}
  </p>
{/each}

This works, but feels a little awkward, and now you have to loop over the array multiple times. In a large component, you'd also have to jump between the template where the variable is used and the script where it's defined when making changes.

One final option is to extract a new component...

<script>
  import Box from './Box.svelte';
  let boxes = [
    {width: 1, height: 2},
    {width: 5, height: 2.5},
    {width: 2, height: 4}
  ];
</script>

{#each boxes as box}
  <Box {box}></Box>
{/each}

<!-- Box.svelte -->
<script>
  export let box;

  $: area = box.width * box.height;
</script>

<p class:big={area > 10}>
  {box.width} * {box.height} = {area}
</p>

... but this seems like overkill for such a simple use-case.

Before Svelte 3.46, you would need to choose one of these options. Now, there's an additional solution: local constants.

The solution: local constants

Instead of adding logic to the script block, you can declare a constant directly in the markup itself with @const.

{#each boxes as box}
  {@const area = box.width * box.height}
  <p class:big={area > 10}>
    {box.width} * {box.height} = {area}
  </p>
{/each}

This is more readable, since the value is declared directly where it is used, and more efficient, since it only computes the value once.

The name “const” was chosen because it behaves like a constant: it is read-only and can't be assigned to. Also, like the native JavaScript const, it is scoped to the block it was declared in. The following template produces compiler errors:

{#each boxes as box}
  {@const area = box.width * box.height}
    <!-- Error: 'area' is declared using {@const ...} and is read-only -->
    <p on:hover={() => area = 50}>
        {box.width} * {box.height} = {area}
    </p>
{/each}
<!-- 'area' is not defined -->
{area}

Despite the similarity to the JavaScript keyword, there is no corresponding let or var tag. Also, unlike const in JavaScript, variables declared with @const can be used before they are declared. The following example is valid, despite area being used before it's declared with @const.

{#each boxes as box}
  <p>
    {box.width} * {box.height} = {area}
  </p>
  {@const area = box.width * box.height}
{/each}

Destructuring inside #each

@const will also make it easier to destructure objects inside #each blocks. Currently, you can destructure a variable inside an #each block like this:

{#each boxes as {width, height}}
  <p>{width} * {height} = {width * height}</p>
{/each}

However, once you do that, you don't have a reference to the original object any more. If you want to use the original object (e.g. to pass to another component), you need to recreate it.

{#each boxes as {width, height}}
  <p>{width} * {height} = {width * height}</p>
  <Box box={{width, height}} />
{/each}

If properties are added or removed from the original object, you need to keep this second object up-to-date as well. This can be easy to forget.

Now you can destructure the object with @const, while keeping a reference to the original object.

{#each boxes as box}
  {@const { width, height } = box}
  <p>{width} * {height} = {width * height}</p>
  <Box box={box} />
{/each}

It takes an extra line, but it means that you don't need to introduce a duplicate object.

Improving readability

Using @const can also improve the readability of your code by letting you name a variable for what would otherwise be an inline expression. For example:

<!-- Option 1: long, complex inline expression -->
{#each boxes as box}
  {#if box.width < 30 && box.width > 10 && box.height % 3 === 0}
  <!-- Do some conditional rendering... -->
  {/if}
{/each}

<!-- Option 2: extract into a local constant -->
{#each boxes as box}
  {@const boxFitsTheRoom = box.width < 30 && box.width > 10 && box.height % 3 === 0}
  <!-- The expression is named, which can help
    others understand the purpose of this code -->
  {#if boxFitsTheRoom}
  <!-- Do some conditional rendering... -->
  {/if}
{/each}

While there's no need to do this for every if statement, it can make your code much more understandable when you have lengthy inline expressions.

Limitations

The new tag does have a few limitations.

Only allowed in certain contexts: @const is only allowed as a direct child of {#each}, {:then}, {:catch}, <Component /> or <svelte:fragment />. These are all block types where a new scope is created. You can't use it by itself at the top level of a template or inside an {#if} / {:else} block, though the latter does have an open feature request.

Doesn't support non-standard JavaScript: because JavaScript expressions inside the markup section of a Svelte component are not preprocessed, you won't be able to write expressions in a const tag that use non-standard JavaScript (e.g. TypeScript or syntax that requires Babel plugins).

Also note that at time of writing there are still some open bugs around this feature:

Fix rvalue error when using arrow functions in {@const} #7206
@const declaration inside components ignored #7189
Unclear error message comes if const is already declared in <script> section #7221
Object property access in callbacks within @const statements are being treated as separate variables #7326

Wrapping up

I've already found @const to be very useful to improve the readability of my code. Keep it in mind next time you're writing Svelte!

The original RFC is well worth a read for some different perspectives on whether introducing this tag is a good idea or not. It's also interesting in context of RFCs #32 (local <style scoped>) and #34 (inline components). Taken together, these RFCs would allow including multiple components inside a single file. However, at time of writing, only #33 (local constants) has been accepted.

How to use Svelte's style directive

Geoff Rich — Mon, 31 Jan 2022 16:50:17 +0000

Svelte 3.46 released a new feature: style directives! In this post I'll show you how to use them and the advantages they have over setting the style attribute directly.

The style attribute

A common strategy for writing dynamic styles in Svelte is to apply the styles directly as an attribute. For example, here's how you can make a box move around the screen with a couple of range sliders.

<script>
  let xPos = 50;
  let yPos = 50;
</script>

<label for="positionX">X </label>
<input id="positionX" type="range" bind:value="{xPos}" />

<label for="positionY">Y </label>
<input id="positionY" type="range" bind:value="{yPos}" />

<div class="box" style="left: {xPos}%; top: {yPos}%">
  ({xPos}, {yPos})
</div>

<style>
  .box {
    height: 80px;
    width: 80px;
    background: pink;
    position: absolute;
  }
</style>

The key part here is style="left: {xPos}%; top: {yPos}%" on the div, which takes the xPos and yPos state variables and sets the element's styles accordingly.

This works well, but can get awkward as you add more properties, especially if those properties are conditionally applied. For instance, look at the following example from the style directive RFC:

<div
  style="
    position: {position};
    {position === 'absolute' ? 'top: 20px;' : ''}
    {pointerEvents === false ? 'pointer-events: none;' : ''}
  "
></div>

It would be easy to forget a semicolon or mishandle a ternary statement and break your dynamic styles. Enter: style directives! 🕺

Style directives

In Svelte, a style directive is an attribute applied to an element in the format style:property={value}, where property is a CSS property name and value is the value of that property. By using style directives, you don't need to worry about properly formatting the CSS string, since you set individual properties instead. If you're using Svelte 3.46 or later, the above example can be rewritten like so to use style directives:

<div
  style:position="absolute"
  style:top={position === 'absolute' ? '20px' : null}
  style:pointer-events={pointerEvents ? null : 'none'}
></div>

And the sliding box example can be written like this:

<div class="box" style:left="{xPos}%" style:top="{yPos}%">
  ({xPos}, {yPos})
</div>

This is about the same amount of code, but is easier to understand and less prone to errors from writing an invalid CSS string.

You can use style directives with any CSS property, including CSS custom property definitions.

<div style:--super-cool-custom-property="orange"></div>

There's also a shorter syntax available if your variable has the same name as the CSS property you're setting. The below two are equivalent:

<div style:color={color}></div>
<div style:color></div>

In the case when the style attribute and style directive set the same properties, the style directive will take precedence.

<div style="margin-top: 1rem; color: red" style:color="blue">
  I will have 1rem top margin and my color is blue.
</div>

Style optimizations

By using style directives, you also make sure that Svelte will update the element's styles in an optimal way. This was also possible with the style attribute, but it was easy to accidentally opt-out of the optimization.

Let's look again at the sliding box example.

<div class="box" style="left: {xPos}%; top: {yPos}%">
  ({xPos}, {yPos})
</div>

When you compile this component, it turns into two calls to setProperty:

div.style.setProperty('left', xPos + '%');
div.style.setProperty('top', yPos + '%');

(If you're ever curious what your Svelte component code turns into, the "JS output" tab of the REPL is a great place to start.)

Svelte performs some clever optimization here and will only set the property that changes. So, if only xPos changes, Svelte will only call setProperty('left', xPos + '%'), and not update top. This makes the style updates more efficient.

However, when using the style attribute, it is easy to accidentally opt-out of this optimization. If you construct the style attribute outside of the template, Svelte can't easily determine how to optimize it and won't try. Instead, it will set the entire style attribute when either variable is updated. So given this code...

<script>
    let xPos = 50;
    let yPos = 50;

    $: boxStyle = `left: ${xPos}%; top: ${yPos}%`;
</script>

<div class="box" style={boxStyle}>
    ({xPos}, {yPos})
</div>

...Svelte won't set left and top individually, and instead sets the entire style attribute every time xPos or yPos changes:

div.setAttribute(style, boxStyle);

Per the original PR that added this optimization, this will almost always be slower than setting the individual properties. So, it's better to construct the style attribute directly in the template so that Svelte can optimize it.

However, with style directives, you don't need to think about any of this! Since each style directive corresponds to a single CSS property, it's easy for Svelte to make those same optimizations, even if the value comes from the <script> block.

<script>
    let xPos = 50;
    let yPos = 50;

    $: left = `${xPos}%`;
    $: top = `${yPos}%`;
</script>

<!-- This is optimized the same way as the original example -->
<div class="box" style:left style:top>
    ({xPos}, {yPos})
</div>

By using style directives, you make sure that your dynamic styles are applied in an optimized way without needing to think about it.

Limitations

Style directives are great, but they have a few limitations.

Exclusive to elements: Like most Svelte directives (with the exception of on:), this does not work on components. There is an open RFC to allow forwarding directives to components, which would include style directives. However, this RFC has not been accepted at time of writing.

Shorthand only works with dash-less properties: Since the property used in the style directive uses the same name as the equivalent CSS property, you can't use the shorthand with properties that contain a dash. This is because you can't use - in a JavaScript variable (e.g., you can't declare a variable with the name border-color).

<!-- This is valid -->
<div style:border-color={borderColor></div>
<!-- This is not valid -->
<div style:border-color></div>

No camel case: Some comments on the original RFC suggested allowing the camel-cased property as well (e.g. style:borderColor), but that suggestion was not accepted. The reasoning was that it's more consistent with the rest of Svelte. For example, you need to do the same with class directives:

<div class:is-active={isActive}>

No style object: Unlike React, you can't pass an object of styles to the style attribute: it needs to be a string. If you do want to do this, it would be fairly simple to solve in userland.

Should you use the style directive for everything?

You shouldn't use style directives for all of your component styles. I would avoid using it if your styles are purely static. For example, there is no need to use style directives on the following component:

<div class="box" style:background-color="red" style:height="100px"></div>

It would be better to put these styles in the style block of the component instead:

<div class="box"></div>

<style>
    .box {
        background-color: red;
        height: 100px;
    }
</style>

This is better for performance, since everything in <style> is compiled to pure CSS without using any JavaScript to apply the styles. I would only use the style attribute and style directives for styles where the values are changing or are supplied from outside the component.

Wrapping up

This feature doesn't enable anything you couldn't do before, but it's a nice bit of syntactic sugar that helps ensure your inline styles are optimized. Go forth and style!

The many meanings of $ in Svelte

Geoff Rich — Wed, 15 Dec 2021 17:18:16 +0000

If you're writing Svelte code, you'll notice that $ can have multiple different meanings, depending on the context. For example, look at this code snippet — $ is used in three different ways! If you're new to Svelte, or to JavaScript in general, it can be confusing to keep them all straight.

$: console.log(`Total: ${$count}`);

In this post, I'll show all the different meanings that $ can have in Svelte.

First, let's start with the primary uses of $ in Svelte: reactive statements and reactive stores.

Reactive statements

In a Svelte component, prefixing a statement with $: marks the statement as reactive — it will run whenever the variables referenced in that statement change. Here's a classic example. Whenever num changes, doubled is automatically set to the correct value.

<script>
    let num = 0;
    $: doubled = num * 2;
</script>

<p>Num: {num}</p>
<p>Doubled: {doubled}</p>
<button on:click={() => num++}>
    Increment
</button>

It's also possible to have an entire reactive block that runs when the variables referenced inside it change.

<script>
  let num = 0;
  let doubled = 0;
  $: {
    doubled = num * 2;
    console.log(num, doubled);
  }
</script>

This is a core concept of Svelte. If you're not familiar with it, go review the section of the Svelte tutorial on reactivity.

This is valid JavaScript, since it uses the obscure label syntax. However, its reactive properties are unique to Svelte, and specifically to Svelte components. Using this syntax inside a regular .js file will not make a statement reactive.

Since this is a valid label, you can exit a reactive block early the same way you'd break out of a regular label. This example will keep track of the number of evens, but only until the counter reaches 10. At that point, break $ will exit the block early.

<script>
    let counter = 0;
    let evens = 0;

    $: {
        if (counter > 10) {
            break $;
        }
        if (counter % 2 === 0) {
            evens++;
        }
    }
</script>

<button on:click={() => (counter++)}>
    Increment
</button>
<p>
    Counter: {counter}, evens before 10: {evens}
</p>

You won't need to use this very often, but it's useful to know about.

Accessing store values

The other primary use of $ you'll see in a Svelte component is when referencing the current value of a store. In Svelte, a store is any object with a subscribe method that allows you to be notified when the value of the store changes. It's especially useful when you want a reactive value to be accessible from muliple components in your application, since the store can live outside of a Svelte component.

If you wanted to get the current value of a store in a Svelte component and have it automatically update when the store changes, you could do something like the following.

<script>
  import count from './count';
  import {onDestroy} from 'svelte';

  let _count;

  const unsubscribe = count.subscribe(val => (_count = val));
  onDestroy(() => {
    unsubscribe();
  });
</script>

This code subscribes to the count store, updates the local _count variable when the store changes, and unsubscribe from the store when the component is destroyed. However, this is a lot of boilerplate.

Thankfully, Svelte has a special syntax to make this sort of thing easy. Inside a Svelte component, we can reference the current value of the count store with the variable $count. By using this syntax, Svelte will take care of subscribing and unsubscribing to the store for us.

As with reactive declarations, this syntax only works inside a Svelte component. In regular JS files, you'll need to subscribe to the store manually.

Comparing reactive statements and reactive stores

Those are the two primary ways $ is used inside Svelte. If the dollar sign has a colon after it ($:), then it indicates a reactive statement. If it is at the start of a variable name inside a Svelte component, then it's accessing a reactive store value. In general, when you see $ in a Svelte component, you should think reactivity.

Note that there are often times where you'll want to combine the two. Referencing a store value in the <script> block with $ does not mean that value will automatically be updated when the store changes. In the following example, doubledCount will not be automatically updated unless you mark that assignment as reactive with $:.

<script>
    // count is a store
    import count from './count';

    // doesn't keep value updated
    let doubledCount = $count * 2;

    // keeps value updated
    $: doubledCount = $count * 2;
</script>

This could seem unintuitive — didn't I just say that a store is reactive? Yes, but it's only reactive in that we can be notified any time the value changes. If we want to derive a value from it, we still need to mark that statement as reactive as well.

This is a little difficult to wrap your head around, so see this alternate explanation in r/sveltejs if you're still having trouble.

However, those are not the only times you'll see $ in a Svelte component. $ is used in other ways, both in Svelte and in vanilla JavaScript in general. Let's go over a few more examples.

Template literals

This is not Svelte-specific, but is worth mentioning, since it's a common technique in modern JavaScript. When writing template literals in JavaScript, you can use ${var} to insert the value of a variable into the template string.

let a = 'running';
let b = 'walking';
// both output "running and walking"
console.log(a + ' and ' + b); // without template literals
console.log(`${a} and ${b}`); // with template literals

Where this could get confusing is if you combine template literals with reactive statements and stores! Make sure you can pick out what each $ means in the below example.

<script>
  import {writable} from 'svelte/store';
    let num = 0;
    let count = writable(0);

    $: console.log(`num is ${num} and the store is ${$count}`);
</script>

$$props, $$restProps, and $$slots

These are globally-available variables inside a Svelte component. $$props contains all the props passed to the component, $$restProps contains all the props that were not explicitly exported by the component (which useful for wrapping native HTML elements like <input>), and $$slots contains the slots passed to the component. Here, \$\$ doesn't indicate that this is a store value; it's just a naming convention.

In fact, their naming mirrors how Svelte names things internally. For example, if you look at the code Svelte generates, you'll see reference to similarly-named variables like $$self and $$invalidate.

function instance($$self, $$props, $$invalidate) {
  let name = 'world';
  const click_handler = () => $$invalidate(0, (name += 'a'));
  return [name, click_handler];
}

The client-side component API also prefixes its methods with $ to avoid colliding with methods defined on the component instance.

Creating a derived store

When creating a derived store, it is common to prefix the values of the store in the derived callback with $. You'll see this in the derived store examples in the Svelte docs.

import {derived} from 'svelte/store';

const doubled = derived(a, $a => $a * 2);

This is not required and does not indicate anything special — it works the same in and out of Svelte components. It just provides an easy way to distinguish the variable in the callback (which has the updated value of the store) and the reference to the store itself.

Wrapping up

While it might seem difficult to keep track of all these at first, given enough experience you'll get the hang of it. It's most important to understand the difference between the first three examples. You're less likely to encounter the others until you reach more advanced scenarios.

Svelte's lifecycle methods can be used anywhere

Geoff Rich — Tue, 30 Nov 2021 17:19:44 +0000

I don't think it's widely known that you can call the Svelte lifecycle methods (onMount, onDestroy, beforeUpdate, afterUpdate) outside of a component. It is mentioned in the Svelte docs and tutorial, though it's easy to gloss over.

The onMount function schedules a callback to run as soon as the component has been mounted to the DOM. It must be called during the component's initialisation (but doesn't need to live inside the component; it can be called from an external module).

onMount and friends are just functions that schedule another function to run during a point in the current component's lifecycle. As long as you call these functions during a component's initialization, you can call them from anywhere. This means you can share lifecycle-dependent functionality between multiple components by putting it in a separate file, making it more reusable and reducing boilerplate.

Let's look at a few examples.

Running a callback after a given interval

You can write the following Svelte code to start a timer that tracks how long the page has been open. We wrap the setInterval call inside onMount so that it only runs in the browser, and not when the component is being server-rendered.

By returning a cleanup function from onMount, we tell Svelte to run that function when the component is being destroyed. This prevents a memory leak.

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

  let count = 0;

  onMount(() => {
    const interval = setInterval(() => {
      count += 1;
    }, 1000);
    return () => {
      clearInterval(interval);
    };
  });
</script>

<p>
  This page has been open {count} seconds.
</p>

But what if you want to use this code in multiple components? You may have thought that because this code uses a component lifecycle method that it has to stay with the component. However, that's not the case. We can move this code to a separate module, as long as the function calling onMount is called when the component is initializing.

// interval.js
import {onMount} from 'svelte';

export function onInterval(fn) {
  onMount(() => {
    const interval = setInterval(fn, 1000);
    return () => clearInterval(interval);
  });
}

<script>
  import {onInterval} from './interval.js';

  let count = 0;
  onInterval(() => (count += 1));
</script>

<p>
  This page has been open {count} seconds.
</p>

Now we have the same behavior, but now it can be reused across multiple components! You can find a similar example using onDestroy instead in the Svelte tutorial.

A store that tells you if a component has been mounted

We can also use onMount to make a store that tells you whether a component has finished mounting or not. This code is from the svelte-mount package:

// mounted.js
import {onMount} from 'svelte';

export const mounted = {
  subscribe(fn) {
    fn(false);
    onMount(() => fn(true));
    return () => {};
  }
};

I found this a little hard to parse at first, but what we have here is a custom store. Per the Svelte docs, a store is any object with a subscribe method that takes a subscription function. When a component subscribes to this store, the subscription function is first called with false . We then wrap a call to the subscription function in onMount so that it is set to true once the component is mounted.

Because this code is in the subscribe function, it will run for each component that subscribes to the store, meaning that onMount will refer to a different component's lifecycle each time it's called.

Here's an example of where this store would be useful. Normally, transitions don't play on initial render, so by adding the element after onMount has completed we allow the transition to play. By using the mounted store, we remove some boilerplate — we don't have to make a state variable to track if the component has mounted and update it in onMount. Nifty!

<script>
  import {mounted} from './mounted';
  import {fade} from 'svelte/transition';
</script>
<h1>
  Hello world
</h1>
{#if $mounted}
<p in:fade>
  Component has been mounted.
</p>
{/if}

You can also set the intro property when creating the component to force transitions to play on initial render, though that won't work in a server-rendered context like SvelteKit.

Track the number of times a component is rendered

This example is a bit contrived, but still interesting. Someone asked a question on r/sveltejs about how to track how many times a component has re-rendered in a way that can be shared across multiple components. They gave the following React hook as an example.

function useRenderCount() {
  const [count, setCount] = useState(0);

  useEffect(() => {
    setCount(count + 1);
  });

  return count;
}

// used in a component like so
function MyComponent() {
  const count = useRenderCount();

  return <p>{count}</p>;
}

Many folks suggested using the afterUpdate Svelte lifecycle method inside the component, but didn't realize that it could be moved outside the component as well. We can re-create this behavior completely independent from the component by combining afterUpdate with a writable Svelte store.

import {writable} from 'svelte/store';
import {afterUpdate} from 'svelte';

export default function trackUpdateCount() {
  const count = writable(0);

  afterUpdate(() => {
    count.update(c => c + 1);
  });

  return count;
}

And it can be used like so, without needing to add any lifecycle boilerplate to the component itself:

<!-- Input.svelte -->
<script>
  export let name = 'test';

  import trackUpdateCountfrom './trackUpdateCount';
  const count = trackUpdateCount();
</script>

<p>Hello {name}! Updated {$count} times</p>
<input bind:value="{name}" />

Here's a REPL if you want to try it out.

I haven't quite wrapped my mind around it, but you can even use afterUpdate in Svelte to replicate React's useEffect hook. See this example from Rich Harris, which I found in an interesting GitHub issue discussing the edges of Svelte's reactivity.

Cleaning up subscriptions

Another common use of lifecycle methods is to clean up store subscriptions. When you use Svelte's special $store syntax inside a component, Svelte automatically subscribes to the store and unsubscribes when the component is destroyed. However, if you subscribe to a store in a regular JavaScript file, you need to unsubscribe manually. This is a great opportunity to use onDestroy — that way, a single file can handle the cleanup instead of requiring the importing components to do it.

At a high level, it could look something like this. Note that this is in an external file, not a Svelte component.

// store.js
import {writable} from 'svelte/store';
import {onDestroy} from 'svelte';

export function createStore() {
  const items = writable([]);

  const unsubscribeItems = items.subscribe($items => {
    // do something when items changes
  });

  // we clean up the subscription ourselves,
  // instead of making the component do it
  onDestroy(() => {
    unsubscribeItems();
  });

  return items;
}

We can then call this function to initialize the store in a component, and the subscription from this file will be automatically cleaned up when the component is destroyed.

For a more concrete example, take a look at this function. We return two stores, items and selected. The selected store is used to track which items are selected, and is generally controlled by the consuming component. However, when items changes, we want to do one of two things:

If all items were selected, all items should still be selected (regardless of any overlap)
If a subset of items were selected, we should keep any common items selected. So if selected was [2,3] and the new items are [2,4,6], then we should update selected to be [2] .

Here's what the function looks like, and a REPL to demo how it's used.

import {writable, get} from 'svelte/store';
import {onDestroy} from 'svelte';

export function createSelectedStore(initialItems) {
  const items = writable(initialItems);
  const selected = writable(new Set());

  let oldItems = initialItems;

  const unsubscribeItems = items.subscribe($items => {
    const _selected = get(selected);
    if (oldItems.length === _selected.size) {
      // if all items were selected, select all of the new items
      selected.set(new Set([...$items]));
    } else {
      // otherwise, only select items that are shared between the old and new set
      const commonItems = [...$items].filter(item => _selected.has(item));
      selected.set(new Set(commonItems));
    }
    oldItems = $items;
  });

  onDestroy(() => {
    unsubscribeItems();
  });

  return {
    items,
    selected
  };
}

Because we subscribe to the items store so that we can update the selected store, we need to unsubscribe from it in onDestroy.

In practice, I used a store like this in my site to filter Marvel comics released in a given year. For each year, users can filter the list of comics for different creators (e.g. only view comics by Chris Claremont). When changing from one year to the next, I want to preserve the filter state as outlined above — if the creators for the next year contain creators that were selected from the previous year, those creators should stay selected.

I simplified my implementation of this for the above example, but you can find the original code on GitHub.

Wrapping up

You won't run into this use case commonly, and not every example I showed needs to be done this way. For some of these examples, you can get a similar outcome using a store. However, it's good to keep this technique in mind for when it becomes necessary.

How to make your Svelte transitions more accessible

Geoff Rich — Wed, 24 Nov 2021 16:40:50 +0000

I gave a talk at last weekend's Svelte Summit on transitions and accessibility. Svelte includes built-in animations that makes it easy to slide, scale, and fly elements in and out of the DOM. However, you need to be careful to not trigger motion sickness in your users. In my talk, I go over which Svelte transitions could cause accessibility issues and how to respect user motion preferences when using them.

We iteratively build a solution to change which transition we use when the user requests reduced motion -- first only using CSS, then detecting the user's motion preference in a Svelte component, to finally encapsulating the logic in a reusable Svelte store.

Following is a full transcript of the talk. You can find my slide deck on Google Slides and the example code on my GitHub. The rest of the event is available to stream on YouTube.

Huge shout-out to the organizers for putting on such a great event and for featuring my talk! Special thanks to Kevin for being very quick to respond to my questions via email, and to Shawn (a.k.a. swyx) for hosting a speaker prep session with some very helpful tips.

Hi, I'm Geoff. I'm a software engineer at Alaska Airlines and today I want to talk about Svelte transitions.

Svelte transitions are amazing! I love that with only a few lines of code and no additional dependencies, you can add some animation that can really make your app stand out. However, you need to be careful. Some people are sensitive to motion. If you use these transitions irresponsibly, they can trigger headaches, dizziness, and even nausea—and this is not how people should feel when they visit your website!

Remember — to quote the official Svelte transition tutorial, "with great power comes great responsibility."

In this talk, I'll talk about the types of animation that can cause accessibility issues, how to detect if the user has requested reduced motion, and how to apply these concepts to Svelte transitions

Motion and accessibility

First, let's talk about motion and accessibility.

So, who does this affect? Well, the largest group affected by animation on the web is people with vestibular disorders. The vestibular system controls your body's sense of balance. If it doesn't function properly, you could experience dizziness, loss of balance, and vertigo, among other symptoms. And animation can often be a trigger for these effects.

According to the National Institute on Deafness and Other Communication Disorders, 4% of American adults report a chronic problem with balance. That's millions of people, many of whom could be using your website or app.

So what kinds of animation can cause issues? Well, there are a few factors.

In general, you want to avoid large amounts of movement. So a button moving a few pixels when you hover it is okay, but something flying across the entire screen could cause an issue. You also want to be careful with multiple elements moving at the same time, especially if they're moving in different directions or at different speeds, such as parallax type movement. And tying any movement to the user's scroll position could be problematic, especially if the element is moving at a different speed or direction from how the user is scrolling.

I recommend the A List Apart article "Designing Safer Web Animation for Motion Sensitivity" from Val Head if you want more detail on this.

So with that in mind, what Svelte transitions deserve extra caution? Well, of the 7 built-in Svelte transitions, 5 of them involve motion. Those would be fly, slide, scale, draw, and crossfade. Transitions like fade and blur that do not involve motion are unlikely to cause issues. This doesn't mean that all uses of these transitions are problematic. What you should look out for is the amount and direction of the motion.

So does that mean if you care about accessibility, you're not allowed to use these transitions? Of course not! But you should provide an alternate experience for users who are sensitive to motion. And that's where prefers-reduced-motion comes in.

Prefers reduced motion

So, Operating systems have started to add ways for users to request reduced motion. [slides show image of iOS and Mac accessibility settings] Here is where you can find it on iOS and Mac, where it's called "reduce motion". [slides show Windows settings and Chrome DevTools] And here's where it is on Windows, under "show animations in Windows". Chrome also lets you set it directly in DevTools, so you can emulate that experience without having to adjust your OS settings.

Here's a video of how iOS behaves when you have this setting enabled. Motion warning for the next few seconds. Normally, opening an app triggers a zooming animation where the app expands into view. However, if you turn on this setting [reduced motion], apps fade in and out instead.

Originally this setting was just for users to control their operating system, but it's also available as a media query in web browsers, and it has great browser support. So, we can detect if a user has requested reduced motion, and adjust our site accordingly.

So let's recap. We know that large amounts of motion can trigger dizziness and nausea in some of our users. We have a media query that can detect if they've requested reduced motion. But how do we apply that to transitions in our Svelte application? Well, there's a few different options. Enough slides. Let’s jump to some code.

Live demo

First, let me show you where we're starting. We have a checkbox here that will hide and show this box. The box has a fly transition applied, so that it flies in and out. I set the y parameter very low to minimize any triggering motion.

<script>
    import { fly } from 'svelte/transition';

    let show = false;
</script>

<div class="input">
    <input type="checkbox" id="show" bind:checked={show} />
    <label for="show">Show box</label>
</div>
{#if show}
    <div class="box" transition:fly={{ y: 30 }}>
        <span class="emoji">📦</span>
    </div>
{/if}

Here's what the transition looks like with reduced motion disabled. [box flies in and out]

So, the first way to respect reduced motion is to disable all animation entirely. Svelte's built-in transitions are applied using native CSS animations, so this snippet will prevent those animations from playing if reduced motion is turned on. Because Svelte's transitions use inline styles, we need to use !important here so that this override applies.

@media (prefers-reduced-motion: reduce) {
  * {
    animation-duration: 0.01ms !important;
    animation-iteration-count: 1 !important;
    transition-duration: 0.01ms !important;
    animation-delay: 0.01ms !important;
  }
}

So, this seems to work. If I enable prefers-reduced motion in Chrome, then the fly animation doesn't play. Is that all there is to it? Well, this approach has some drawbacks.

It's definitely better than not respecting motion preference at all. However, we use animation for a reason. Animation is often essential to make your interface understandable. So we don't want to turn it off entirely.

Remember: it's prefers reduced motion, not prefers no motion.

Instead, we could behave more like iOS does—if reduced motion is requested, change the animation we use to have less motion. On iOS, they change the zoom to a fade instead when an app opens. We could do the same — fade the element in instead of flying it in.

Of course, this approach requires more vigilance on the part of the developer. You need to be intentional when implementing animation and choose what the fallback should be for users with motion sensitivities. But, this approach will result in a richer experience for those users as well.

Even if you do choose to globally disable animation like this, remember that some Svelte animations are applied purely through JavaScript, not CSS. Custom JavaScript transitions and animation using the spring or tweened stores won't be affected by a CSS-only solution. So, it's worthwhile to consider other methods as well.

Now, let's look at how we can detect reduced motion in JavaScript, and change the transition we use accordingly.

This is the same component as before, except now the transition we use is stored in a variable. transitionToUse will reactively update based on the value of reducedMotion. If reduced motion is true, we'll use the fade transition. Otherwise, we'll use the fly transition. But for that to work, we need to set reducedMotion properly.

<script>
    import { fly } from 'svelte/transition';

    let show = false;
    let reducedMotion = false;
    $: transitionToUse = reducedMotion ? fade : fly;
</script>

<div class="input">
    <input type="checkbox" id="show" bind:checked={show} />
    <label for="show">Show box</label>
</div>
{#if show}
    <div class="box" transition:transitionToUse={{ y: 30 }}>
        <span class="emoji">🐱</span>
    </div>
{/if}

First, we'll call window.matchMedia to get a media query list that will tell us if the reduced motion media query applies. We can also add an event listener to this list, so that if the user changes their motion preference, we can immediately react to it instead of only checking on initial load. And just like any time when we add an event listener manually, we need to remove it when the component is destroyed. Finally, if you're doing this in a server-side rendering context like SvelteKit, you need to make sure we're in the browser so that we can use a function from the window.

<script>
    import { fly, fade } from 'svelte/transition';
    import { onDestroy } from 'svelte';
    import { browser } from '$app/env';

    let show = false;
    let reducedMotion = false;
    $: transitionToUse = reducedMotion ? fade : fly;

    const reducedMotionQuery = '(prefers-reduced-motion: reduce)';

    if (browser) {
        let mediaQuery = window.matchMedia(reducedMotionQuery);
        reducedMotion = mediaQuery.matches;

        const setReducedMotion = (event) => {
            reducedMotion = event.matches;
        };

        mediaQuery.addEventListener('change', setReducedMotion);

        onDestroy(() => {
            mediaQuery.removeEventListener('change', setReducedMotion);
        });
    }
</script>

<div class="input">
    <input type="checkbox" id="show" bind:checked={show} />
    <label for="show">Show box</label>
</div>
{#if show}
    <div class="box" transition:transitionToUse={{ y: 30 }}>
        <span class="emoji">🐱</span>
    </div>
{/if}

And that's all there is to it! When we set prefers reduced motion, the box now fades in. After we unset it, the box flies in.

So this works great — now let's make it more reusable. Stores are a great way to extract reactive logic in Svelte. I've updated this example to use a store instead of a local variable, but we still need to implement it.

<script>
    import { fly, fade } from 'svelte/transition';
    import reducedMotion from '$lib/reducedMotionStore';

    let show = false;
    $: transitionToUse = $reducedMotion ? fade : fly;
</script>

<div class="input">
    <input type="checkbox" id="show" bind:checked={show} />
    <label for="show">Show box</label>
</div>
{#if show}
    <div class="box" transition:transitionToUse={{ y: 30 }}>
        <span class="emoji">🐶</span>
    </div>
{/if}

First, we'll get the initial value of the store using the query from before, defaulting to false if we're not in the browser. Then, we'll pass a function as the second argument to the store. This function will be called when the store gets its first subscriber, so it's a great place to set up event listeners. We'll add the listener from before to react to preference changes. We can return a cleanup function to remove the event listener when there are no more subscribers. And just like before, we only want to run this code in the browser.

import {readable} from 'svelte/store';
import {browser} from '$app/env';

const reducedMotionQuery = '(prefers-reduced-motion: reduce)';

const getInitialMotionPreference = () => {
  if (!browser) return false;
  return window.matchMedia(reducedMotionQuery).matches;
};

export default readable(getInitialMotionPreference(), set => {
  if (browser) {
    const setReducedMotion = event => {
      set(event.matches);
    };
    const mediaQueryList = window.matchMedia(reducedMotionQuery);
    mediaQueryList.addEventListener('change', setReducedMotion);

    return () => {
      mediaQueryList.removeEventListener('change', setReducedMotion);
    };
  }
});

And there you have it — a reactive, reusable store to detect the user's motion preference.

Could Svelte make this easier?

So, writing all this code begs the question: could Svelte make any of this easier? And my answer is: maybe! At minimum, I think it would be good to document the need to respect motion preferences when using Svelte transitions.

However, I think it's tricky to figure out just how much of what I just showed could or should be integrated into Svelte itself. For instance, I wouldn't want to add that animation-disabling CSS snippet into the template and call it a day. As I talked about earlier, there's a lot more nuance involved there. At its core, this is a design question, and there isn't going to be an answer that's the same for every app. But maybe there's a way to make it easier to adjust animation based on motion preference, by adding similar code to what I showed you.

There is an open GitHub issue around this already. If you have thoughts or suggestions as to how to make this sort of thing easier, go comment over there. But at the end of the day, it’s our responsibility to make sure the code we write is accessible. Anything Svelte does won't change that.

Thanks for watching. If you want to learn more, here are some resources I found helpful while preparing for this talk, by designers and developers much more knowledgeable about this than I am. At the bottom are two articles I wrote on my personal blog about this topic earlier this year. They formed the foundation for this talk.

Smashing Magazine, “Respecting Users’ Motion Preferences” and “Designing With Reduced Motion for Motion Sensitivities”
CSS-Tricks, “Revisiting prefers-reduced-motion, the reduced motion media query”
web.dev, “prefers-reduced-motion: Sometimes less movement is more”
geoffrich.net, “A Svelte store for prefers-reduced-motion” and “Accessible Svelte Transitions”

You can find me on Twitter @geoffrich_, or at my personal site, geoffrich.net, where I regularly write about Svelte. If you have any questions, feel free to reach out on Twitter. Thanks again!

Photo by Nathan Anderson on Unsplash.

What Svelte's accessibility warnings won't tell you

Geoff Rich — Wed, 20 Oct 2021 20:15:32 +0000

Svelte's accessibility (often shortened to "a11y") warnings are one of the framework's standout features. Per Rich Harris, Svelte is an "a11y-first framework" that "will let you write non-accessible markup, but it won't respect you for it." Accessibility warnings in the compiler have been a part of the framework since version 1.38, and are highlighted in the first section of the tutorial.

When I was first learning about Svelte, I was intrigued by this feature. However, I couldn't find much discussion on what these warnings include. Most mentions of this feature only give image alt text as example—certainly important, but only a small part of making an accessible web page. Also, until recently, there wasn't much mention of accessibility in the Svelte docs, though now there's a list of the compiler a11y warnings.

In this post I will answer a few questions:

Do frameworks make for less accessible sites?
Just how effective are Svelte's a11y warnings?
What won't they warn you about?
How could Svelte improve?

The curse of React

Yes, in an article about Svelte I'm starting off by talking about React. Bear with me.

[React] has greatly simplified the building of complex interactions so everybody rolls their own--but they don't realize they've messed up the accessibility of their apps.

— Ryan Florence

The Curse of React is that the average React app is less accessible than the average jQuery app. This is because React simplified building UI to the point that developers write their own complex UI components instead of using a standard library like jQuery UI. However, the average developer doesn't know everything that's needed to make something like an autocomplete accessible, resulting in less accessible components.

This curse isn't unique to React—at this point, the Curse of React is really the curse of UI frameworks in general, including Svelte. Since Svelte is still a developing ecosystem, it suffers even more from the Curse of React. There aren't a lot of options for Svelte component libraries, let alone accessible ones. And because React is still the biggest framework, the best thinkers in accessibility are focusing on that ecosystem (e.g. React ARIA, Downshift, and others).

I hesitated to mention this last point because it technically has to do with adoption, but I cannot separate it from React's merits: it seems to have the best thinkers on accessibility and interaction design right now. No other ecosystem has projects like Adobe and Devon Govett's React Aria that has extensively thought through and tested for WAI-ARIA so you don't have to. Ditto Segun Adebayo's Chakra UI.

—Swyx, Svelte for Sites, React for Apps

So, just like React, it's easy to build an inaccessible component with Svelte. But because Svelte is relatively small, there aren't any battle-tested, widely used component libraries that are more likely to be accessible and there's less for Svelte devs to reuse.

But Svelte's compiler has accessibility warnings, right? So won't that make my Svelte app accessible?

Well, it's complicated. But in summary—no.

What accessibility issues does the Svelte compiler catch?

First, I want to review which accessibility issues the compiler will warn you about. You can find all the warnings listed in the Svelte docs. In addition, the code behind these warnings is very readable. If you're interested, look at the Element.ts file in the Svelte compiler and search for "a11y".

Reviewing each warning individually could get pretty dry, so I'll provide a high-level overview of the types of issues that will trigger a compiler warning.

Most of Svelte's accessibility warnings focus around attributes on single HTML elements:

required attributes that are missing (e.g. no alt attribute)
misplaced attributes that shouldn't be there (e.g. aria-hidden on a heading)
invalid attributes (e.g. writing role="potato")

There are also some checks around the structure of the markup in a single component, e.g.:

<figcaption> should be a child of <figure>
label should have a for attribute or a child <input>
anchors and headings should have child text content

The rest of the warnings are a grab bag of accessibility best practices—markup that is technically valid, but is not recommended due to its accessibility impact, e.g.:

Don't use <marquee />
Don't use autofocus
Don't use positive tabindex values

Most of Svelte's checks are copied from eslint-plugin-jsx-a11y. There is also an open GitHub issue detailing additional checks the Svelte team would like to add.

What issues will the compiler overlook?

However, even if all the suggested rules in the above GitHub issue were added, there are still large categories of issues that the Svelte compiler will overlook. If you take one thing away from this post, let it be this:

Just because you don't see any Svelte compiler warnings doesn't mean you made an accessible website.

I will focus on issues that aren't detected because they're difficult or impossible to detect with a compiler, not just because no one has implemented them yet.

Dynamic values

If the value of an attribute is dynamic, the compiler can't be sure what will be placed in that attribute at runtime and will not validate that value.

For example, the compiler warns you if you write <a href="#">. But if you make a variable that stores "#" and set href to that variable, the compiler won't warn you. This also applies if the value of that attribute is a component prop.

<script>
    let href = "#";
</script>

<a href={href}>I'm under the radar</a>

This isn't a warning because it's hard for the compiler to determine all the possible values for that variable at compilation time, especially if that variable is populated by an external API response. It can't know if the value of that attribute is an accessibility issue or not.

This limitation is true for any attribute that the compiler would normally warn you about.

Anything that requires a larger view of the app

Not everything can be detected at the component level. Some issues depend on how the component is used in an application, or on an element present in another component. Many of these checks are easier to do at runtime with a tool like Axe, which has a full view of the rendered application. Svelte's compiler only looks at one component at a time, and has a limited view of the app as a whole.

For example, you shouldn't skip heading levels and go from an <h2> to an <h4>. However, if each heading is in a different component, Svelte won't know that you're skipping a heading level. It's not possible to determine that using static analysis.

<!-- Heading2.svelte -->
<h2>
    <slot></slot>
</h2>

<!-- Heading4.svelte -->
<h4>
    <slot></slot>
</h4>

<!-- App.svelte -->
<script>
    import Heading2 from './Heading2.svelte';
    import Heading4 from './Heading4.svelte';
</script>

<Heading2>
    I'm an h2
</Heading2>

<Heading4>
    I'm an h4
</Heading4>

Similarly, duplicate IDs can be an accessibility issue. If two inputs have the same ID, the browser won't know which label goes with which input. However, if you use the same ID in two different Svelte components, the compiler won't be able to determine if that's an issue. Even if it was looking for duplicate IDs, it doesn't know if those two components are ever rendered at the same time.

Even warnings the Svelte compiler does have, like labels must be linked to an input, aren't perfect and have blind spots. With the way this warning is currently implemented, Svelte only requires the label to have a for attribute or to wrap an input. It doesn't require an input with the matching id to exist or for the input to be associated with a label.

<!-- This passes, even if there is no input with id="test" -->
<label for="test"></label>

<!-- This passes, even though there is no associated label -->
<input type="text">

This is because it's very hard for the compiler to be certain that there is an accessibility issue here. In the first case, there could be an input with id="test" somewhere, be that another component or even outside the Svelte app entirely. The second case with the standalone input could be easier to detect, but any implementation would likely introduce false positives, where the compiler reports an accessibility issue that is not there.

This is one of the central conundrums of the Svelte compiler's accessibility checks: finding the balance between false positives and false negatives. The compiler optimizes for false negatives, or not reporting accessibility issues that are present, so that the number of false positives is minimized. If there are too many false positives, people stop trusting the accessibility warnings. However, this means there are many potential accessibility issues that the compiler will not detect.

Styling issues

If the accessibility issue is in CSS, Svelte won't detect it. Two examples of these issues are making sure your text has appropriate color contrast and that keyboard focus is visible when navigating the page.

These issues are unlikely to become a compiler warning. As above, this is way easier to check in the browser.

Anything that's subjective

If it can't be a straightforward yes/no answer, the compiler is not going to warn you about it. Svelte's current accessibility checks are just lint rules: they're going to help you get the little things right, but they're not going to guarantee that you've written good code. For example:

Is animation on the page going to trigger motion sickness?
Is there a better semantic HTML element you could use?
Is your alt text meaningful? Is that image really decorative?
Is the page usable when used with screen magnification software?
Is your custom dropdown/modal/autocomplete usable by a screen reader? By voice controls? By someone only using the keyboard?

Accessibility can't be reduced to a series of compiler warnings. So much about accessibility is a spectrum, not a binary yes/no. These just aren't things that a automated checker can be certain about.

Summing up

Those are some of the issues the compiler is unlikely to warn you about anytime soon. And I don't think we should expect it to. There are limitations to being a compiler, and many of these issues are much easier to check in the browser using another automated tool or though manual testing.

And honestly, there are limits to automated accessibility checks. In general, passing some sort of automated accessibility check is not a guarantee that your page is accessible, the Svelte compiler included. For more on this, I recommend "What we found when we tested tools on the world’s least-accessible webpage" and "Building the most inaccessible site possible with a perfect Lighthouse score." As developers, we can't pass the responsibility of making our sites accessible to an automated tool.

The question is: do Svelte developers understand these limitations exist?

False confidence

I put a poll on Twitter a few months ago:

I expect Svelte's accessibility warnings to catch ____ a11y issues.

Where a11y issue is anything that impacts the accessibility of a page (misused attributes, keyboard focus, color contrast, etc)

Some (<20% of issues)

Many (20-50%)

Most (>50%)

All a11y issues

— @geoffrich_ on April 13, 2021

You can't really quantify a11y compliance with percentages—calling your app "80% accessible" is nonsensical. But I wanted to understand people's confidence. If you're building your app in Svelte and you know Svelte has accessibility warnings, what do you think seeing no accessibility warnings means? Does it mean your app is fully accessible? And the results were surprising:

Most a11y issues (28.5% of respondents)
Some a11y issues (26.3%)
All a11y issues (24%)
Many a11y issues (21.2%)

Out of 300 respondents, over half (52%) thought Svelte would catch most or all a11y issues. Almost a quarter thought Svelte would catch all of them. And I don't think that's a correct perception. With my examples above, it's clear that there's so much more to accessibility that Svelte won't warn you about.

Even beyond Svelte, automated accessibility checkers don't catch every issue. According to WebAIM, only 25%-35% of accessibility errors are detectable using any automated tooling, and the Svelte compiler is a subset of that. You're mistaken if you think using Svelte will mean you're warned about any accessibility issue.

I want to emphasize that Svelte hasn't promised that—there's no false advertising happening here. But there also isn't a lot of documentation on Svelte's accessibility warnings. Accessibility is mentioned in the tutorial once. If you're unfamiliar with accessibility, I see how you could assume that it's something the compiler takes care of, just like the compiler takes care of optimizing your code.

How could Svelte be better?

Developers will always have to do something to make sure what they build is accessible. However, I have a few suggestions for Svelte to improve its accessibility tooling and documentation.

Integrate with existing tooling

A lot of the existing a11y warnings have been slow to implement because Svelte has to re-implement work already done in the JSX eslint plugin or in axe-core. Is there a way to use existing packages in the Svelte compiler to detect a11y issues? Building a compiler is hard enough, let alone keeping up to date with accessibility guidance.

Also, with SvelteKit, we now know how someone will be building their Svelte app. There could be a way to integrate runtime accessibility checks into the default template. Adding these checks would massively increase the kinds of issues Svelte could detect. I put in a SvelteKit issue suggesting that.

Merge existing PRs

There are quite a few a11y warning PRs open. Merging these PRs would improve Svelte's existing accessibility tooling.

Documentation

I also think Svelte could improve its documentation around accessibility. Currently, it only lists the available accessibility warnings. React, Vue, and Angular all have dedicated accessibility sections in their docs. These sections detail various considerations, practices, and testing around accessibility. Svelte could do the same, or at least link out to further resources. This would help developers better understand what they're responsible for.

Foster a culture of accessibility

This isn't necessarily on Svelte itself, but on the community. As Svelte developers and content creators, we should take care to make sure what we put out there is accessible, whether that's a blog post, a video, sharing a REPL, or creating a package. Sharing inaccessible demos (for example, a demo that uses <div on:click> instead of <button>) results in people copying that code for their projects and excluding some of their users. We can do better.

Wrapping up

As a developer, you should take ownership of the accessibility of what you build. Releasing an inaccessible app or site does harm to your users. The Svelte compiler will help you write accessible markup, but it won't catch everything—you still need to test your sites for accessibility in other ways. You don't have to be an expert, but you do have to care.

Here's some things you can do that will make a difference:

Run other checkers like Axe, WAVE, or Lighthouse on your webpage.
Make sure you can navigate your site only using your keyboard.
Continue learning about accessibility.
Learn how to use a screen reader.

I'll link some introductory a11y resources down below, and feel free to reach out to me on Twitter or in the Svelte Discord if you have any questions.

We can help educate developers about a11y and make a strong statement about the kind of web we want to be a part of — I think we should.

— Rich Harris

Further a11y resources

Thanks to swyx for discussing these ideas with me back when this was a rejected Svelte Summit talk.

Exploring Marvel Comics' history with SvelteKit

Geoff Rich — Wed, 06 Oct 2021 15:52:20 +0000

tl;dr I launched a new site where you can see Marvel comics published in a given year and retrieve a random comic available on the Marvel Unlimited app. The code is open source on GitHub.

On September 9, the Marvel Unlimited app (MU), which lets you read tens of thousands of Marvel's comics for a monthly fee, got a huge update. While it added some long awaited features such as unlimited downloads, it also wreaked havoc on users' reading history and libraries and removed some beloved features.

One of these features was the ability to sort by date—for example, being able to view every comic released in 1993. This was crucial for those trying to read every Marvel comic in chronological order, as well as those following a yearly comic book reading club like My Marvelous Year.

I was one of those users disappointed by the feature's removal. After I discovered that all the data needed to re-create the feature was available from Marvel's API, I started coding. A few weeks later I launched Marvel Unlimited by Year.

Features

Comics available on MU published in 1977

View all comics available on Marvel Unlimited for a given year. For example, here's 1975.
Each comic's cover links directly to the issue in Marvel Unlimited or the web-based reader, depending on your device.
Sort and filter the results by series, creator, or event.
View a random selection of available comics, or random comics released in a specific decade. The old app had a button that would give you a random comic, though it wouldn't allow you to specify the decade. The MU team have stated that they don't have plans to add the random button to the new app, so I'm glad I was able to make it available on my site.

The random comics page

The tech stack

Svelte and SvelteKit for the app framework. This was my first major project in SvelteKit and I had a great experience. Svelte is my favorite front-end framework to work in, and SvelteKit builds a full-stack app framework on top of it with SSR, server endpoints, and routing, as well as a fast dev environment powered by Vite. Despite it still being pre-1.0, I had very few issues and I'm looking forward to moving some of my work projects over to SvelteKit as soon as possible.
TypeScript on the server and client side. The complexity of the API response made auto-complete a must-have (and by extension, types). SvelteKit gave me the option to set this up automatically, so I didn't have to wrangle any configuration.
Redis cache hosted on Upstash, a serverless option where you pay per-request instead of per-server. Since I had a limited number of API requests per-day, I needed to cache the responses for 24 hours. The random comic functionality is also implemented using Redis queries.
Netlify hosted the deployed site. So far, the traffic hasn't exceeded the limits of their free plan (125k function invocations).
Marvel API for the data. While the documentation doesn't seem like it's been updated recently (the last change announcement was 2014), it still works great and the data is current.

Testimonials

I posted this project on the Marvel Unlimited subreddit last week, and received a glowing response.

Uh, I think I can speak for everyone when I say, holy cow this is great! Super fast and the link to the iOS app works great! I guess it’s true what they say, not all heroes wear capes. I wish I could upvote this multiple times!

Even better than the old app because it does exactly what I used to do, but it loads so much faster!

This is the best thing I've ever seen on Reddit.

It was nice to develop something that others found useful! One of the best things about knowing how to code is being able to create something solving a niche problem that wouldn't otherwise get addressed. These comments also show that SvelteKit provides a speedy user experience as well as a great dev experience.

As a dev myself, I know as well as anyone that rewriting a product with an existing user base is hard. I'm not trying to disparage the development team as part of this effort—I just wanted to restore a feature that I (and many others) found essential, and try out some new dev tools in the process.

Future plans

I'm not done developing this site and still have some features I want to add, such as filtering by release month and listing out available series.

If you're interested, the code is open source on GitHub. You can even run it yourself, though you'll need to provide your own Marvel API keys and Redis connection. Docs are sparse at the moment, though I hope to flesh them out eventually.

Stay tuned for a follow-up post with some of the things I learned on this project.

Photo by Erik Mclean on Unsplash

Notes on Rich Harris' PodRocket interview

Geoff Rich — Tue, 05 Oct 2021 18:21:22 +0000

LogRocket's podcast PodRocket released a new episode with Rich Harris, the creator of Svelte, this morning. There were so many good insights in it that I wanted to pull out some choice quotes and take some notes to share this in a non-audio medium.

I highly recommend listening to the full episode, especially if you're new to Svelte. Even if you're already familiar with Svelte, there are still some great insights to Svelte's philosophy and its position in the current framework landscape.

All these quotes are from Rich Harris. I pulled them from the transcript of the episode and cleaned them up a bit, though the emphasis is mine.

Svelte's advantages

Svelte's advantage is that it lets you write your components declaratively, and then translates it into the underlying DOM manipulation at compile time. This typically makes for smaller bundle size and faster state updates.

Instead of imperatively manipulating the DOM with document.createElement and all of the things that are provided by the platform. It puts a declarative layer on top of that so that you can describe the output that you want, and then the framework's job is to translate that into the underlying DOM manipulations.

It generates typically very small code, which means that your application is going to load very quickly, and the updates, when you have a state change within your application, also take place very quickly, because it doesn't need to regenerate your entire application. It's just surgically updating the part of the page that's affected.

I should say at this point, because this is what I've been telling people about Svelte since it first came around in 2016, the landscape has actually shifted a little bit and other frameworks are, in many cases, becoming a little bit more Svelte-like. So when I talk about these unique advantages, they're not so unique anymore. Svelte's selling point these days is really more about the developer experience it provides. Vue, in particular, has adopted a lot of these techniques and also has some of those bundle size and performance characteristics.

Just JavaScript vs a DSL

There are advantages to staying close to the platform and only using syntax that exists natively, but domain-specific languages (DSLs) have advantages too.

One of the things I say from time to time is that DSLs are actually a good thing. People on the other side, on the just JavaScript side, will be like, "I don't want to learn a domain specific language," because they've been bitten by domain specific languages in the past. But, actually, why wouldn't you want the language to be specific to the domain that you're solving. As long as the DSL doesn't decrease the amount of flexibility that you have, then other things being equal, it's probably a good thing. If it enables you to express the ideas in your application more concisely and more consistently, then it's probably a good thing.

Svelte's primary language is HTML

Svelte's component syntax uses HTML as a base—the fundamental language of the web.

The thesis here is the HTML is the language of the web. JavaScript is not the language of the web. JavaScript is one of the three languages that are sort of contained within HTML, because HTML is designed to contain CSS and JavaScript, whereas a lot of frameworks go the other way. They're like, "JavaScript is the primary language and we're going to try and shoehorn HTML and, in some cases, CSS into JavaScript." Svelte takes this opposite view that you begin with HTML, and then you add JavaScript as necessary.

On SvelteKit's flexibility

SvelteKit is a framework built for the serverless front-end landscape.

It's a full stack application framework that lets you build fully server rendered applications with all of the modern best practices, but it's also very flexible both in how you build your app. You can build a completely single-page app or you can build a completely JavaScript-free multi-page app or something in between, and you can vary it by page; but you can also deploy it to a bunch of different places if it's suitable. Like [if] you're building a very static content site, then you can bake it out of static HTML and then you can just throw that on GitHub Pages or whatever it is.

But if you're doing something that's highly dynamic, then you can have a server component or you can have serverless functions or you can put it inside a Cloudflare Worker, and you can pre-render the parts of your application that are static and dynamically render the parts that are not. And it's really a way of addressing all of the problems, or as many of the problems as possible, that you encounter while building a modern web application.

For more on this topic, see the SvelteKit announcement post, though some things have changed since that was written. Most notably, SvelteKit is now using Vite instead of Snowpack.

What's on the Svelte roadmap?

I liked hearing about what could be next for Svelte, though note that nothing on this list is set in stone. It seems like we can expect more iteration on Svelte core once SvelteKit hits 1.0 and is stable.

I'm almost reluctant to talk about some of these things, because a lot of it is speculative and we're not really sure where some of these ideas are going to land. But we have this long wish list of things that we want to do for Svelte 4.0 and beyond.

Some of it is adopting some of the features that other frameworks have proven out, like streaming SSR and things like that. Some of it is around speeding up our own compiler, so that the feedback loop gets even tighter. Changing how the compiled output is generated such that if you have a very large application, you're paying only a very tiny incremental cost per component. We have some grand ideas about better ways to think about motion inside user interfaces and how that should be tied to the core of a framework as opposed to left to a userland solution.

We have a great many ideas, and I don't want to give them all away. But there's a lot on our plate, and we're pretty excited to get stuck into it when we can.

Does Svelte have more "magic" than something like React?

A common perception is that Svelte has more magic as opposed to a framework like React. However, React has magic too—the difference is that Svelte's magic happens at compile time, while React's magic happens at runtime.

I don't know that that [magic vs explicit is] such a real dichotomy. The differences that Svelte is doing the stuff at build time. It's changing your expectations of how JavaScript works, because it's intercepting assignments and turning those into reactive state changes. React is doing something similar.

If you look at a React function and you don't know what's happening with hooks, then you would look at that code and you'd be very confused about what's happening, because the functions behave in ways that JavaScript functions generally don't. The fact that the return value of a function depends on how many times you've called that function and whether you've called the return value in the past and things like that, that's deeply weird, it's not how JavaScript works at all. You can implement it with JavaScript, but it's not how JavaScript works. They are violating expectations on a fairly fundamental level.

The difference is that they're doing it all at runtime instead of having all of that stuff happen behind the scenes at compile time. And I tend to think that focusing on whether the magic happens at build time or whether it happens at runtime is focusing on the wrong thing. All frameworks involve magic. Svelte is just trying to do the expensive bits of magic before that code gets to the user. That's the only real difference.

On the "framework wars"

Treating web development as a war between one framework or another is not healthy. The people building these frameworks get along and are all trying to improve front-end development and the web as a whole. There is no One True Framework, and different frameworks fill different needs.

I dislike the framework wars framing generally, because what might not be obvious to a lot of people who are users of these frameworks as opposed to actively involved in the development of them, is that... The people who are building these frameworks, we often talk to each other. We by and large know each other. We get along. There's no animosity There's no warring whatsoever.

We hang out in the same spaces and we share ideas with each other, and really we're all, I think, just trying to collectively advance the state of front end development by focusing on the little bits of innovation that we can contribute, and then gradually, all of that stuff filters through the ecosystem and gets shared more widely. And Svelte occupies a part of the landscape that is attractive to a certain kind of developer. React occupies a different part of the landscape. They're both completely fine solutions for the people who are choosing them, and they're not going to be right for everyone and that's fine.

Svelte is no longer an underdog

Svelte is now talked about as one of the "big 4" frameworks. At this point, we can't really consider it an underdog, since so many are aware of it. There are many frameworks with much less name recognition than Svelte.

So are we the underdog? It depends on what you're looking at. There's three big frameworks, right? There's React, Angular and Vue. And if you had to pick a fourth framework, I think most people at this stage would probably say the fourth framework was Svelte. And so if underdog means that you're inside the top four instead of the top three, then absolutely are the underdog.

At the same time, we have a pretty good mindshare at this point. A lot of people in the front end world have heard of Svelte. A lot of people talk about Svelte. There's a whole industry of people doing YouTube videos about Svelte. And I think calling ourselves underdog would be a disservice to the people who are actually laboring on open source projects without getting a whole lot of recognition. I think we have plenty of recognition. And so, I wouldn't claim the underdog label for ourselves by any stretch, but nor are we in any way mainstream.

See the podcast for more, including

How Svelte compares to the virtual DOM (see also: Virtual DOM is pure overhead)
The ideal use case for Svelte
Svelte's two-pronged approach to managing state
How templating works in svelte
Whether a React-specific DSL could help reduce its boilerplate (see also Rich's tweet on the subject)

How Svelte scopes component styles

Geoff Rich — Tue, 07 Sep 2021 13:57:57 +0000

By default, any styles you write in a Svelte component are scoped to that component. This means that the p selector in the following code will only apply to <p> elements inside this component.

<p>This is a paragraph with scoped styles.</p>

<style>
  /* I only affect elements in this component */
  p {
    color: green;
  }
</style>

But how does this scoping actually work? In this post, I'll explain how Svelte scopes styles to your components and the implications for global styles in the rest of your app. I think this topic is interesting on its own, but understanding Svelte's scoping method will also help you better debug your component styles.

This post is accurate for the Svelte version at time of writing (v3.42.4). However, the implementation of Svelte's style scoping is subject to change—in Svelte's lifespan, it has changed several times already—and I don't guarantee that this post will remain accurate.

Classing up the joint

When working on a Svelte app, you may have seen some unexpected CSS classes beginning with "svelte-" in the DevTools inspector. Why are those there? Svelte applies those classes to styled elements in your app so that component styles don't "leak out" to elements outside the component.

For example, the component in the previous section is transformed into the following.

<p class="svelte-dvinuz">This is a paragraph with scoped styles.</p>

<style>
  p.svelte-dvinuz {
    color: green;
  }
</style>

The transformed CSS rule won't apply to <p> elements outside of the component, because they won't have the svelte-dvinuz CSS class applied. Only elements inside the component will match the scoped CSS rule.

The class Svelte adds is not random. It is generated using a hash of the component's styles, making it unique for every component (unless two components styles are exactly the same).

More complex rules

Let's look at what happens when the CSS rules become more complicated. The following component uses a descendant combinator. This is not strictly necessary in this example case (you could target span and li directly), but it's useful for illustration.

<ul>
  <li>Apples <span>🍎</span></li>
  <li>Bananas <span>🍌</span></li>
  <li>Carrots <span>🥕</span></li>
</ul>

<style>
  ul li {
    font-size: 18px;
  }

  ul li span {
    font-size: 24px;
  }
</style>

What are the different ways Svelte could transform this component?

One option is to only apply the scoping class to the first selector in the rule, so the rules become ul.svelte li and ul.svelte li span. However, this could cause unwanted style leakage. If this component contained child components, elements in those components could match the rule.

Another option is to apply the scoping class to every selector in the rule, so the rules would become ul.svelte li.svelte and ul.svelte li.svelte span.svelte. This would prevent any styles from leaking to child components, but it does add the scoping class more times than is necessary. It would also unnecessarily increase specificity, which is a problem we'll return to later.

What Svelte actually does is somewhere in the middle: it applies the scoping class to the first and last selector of each rule. The styles are transformed to the following:

ul.svelte-gxa857 li.svelte-gxa857 {
  font-size: 18px;
}
ul.svelte-gxa857 li span.svelte-gxa857 {
  font-size: 24px;
}

This is the best of both worlds: styles don't leak out (because the rule must start and end inside the component) and we don't add more classes than necessary.

Specificity and scoping

Now if you think you have a handle on things, let's tweak our markup and styles a bit. What styles do you think Svelte generates in this case?

<ul>
  <li><span class="name">Apples</span> <span>🍎</span></li>
  <li><span class="name">Bananas</span> <span>🍌</span></li>
  <li><span class="name">Carrots</span> <span>🥕</span></li>
</ul>

<style>
  ul li span {
    font-size: 24px;
  }

  .name {
    font-size: 18px;
  }
</style>

In this case, Svelte outputs the following CSS:

ul.svelte-1pr62yn li span.svelte-1pr62yn {
  font-size: 24px;
}
.name.svelte-1pr62yn.svelte-1pr62yn {
  font-size: 18px;
}

Woah! Svelte transformed the 3-selector rule the same way, but added the hash class twice to the .name rule! Why would it do that?

This traces back to a concept called CSS specificity. Specificity is how the browser determines what CSS rules should take precedence over others. In general, certain types of CSS selectors are more specific and thus have higher priority. For instance, a class selector (like .list) is more specific than an element selector (like ul). If both .list and ul define a value for font-size, the .list value will win since it's more specific.

Also, the amount of each type of selector matters. The more of a type of a selector in a given CSS rule, the more specific it is. So, a selector with two classes will be more specific than a selector with one class.

I'm drastically over-simplifying things (specificity can support an entire blog post in itself!), so check out web.dev's Learn CSS module for more details.

So, the reason Svelte adds two class selectors instead of one is to keep the specificity order intact. Before the scoping classes were added, the rules had the following specificity order (from highest to lowest):

.name (specificity 0-1-0)
ul li span (specificity 0-0-3)

But after the classes were added the specificity changed. Here's what the specificity would've been if Svelte didn't add the hash class twice:

ul.svelte li span.svelte (specificity 0-2-3)
.name.svelte (specificity 0-2-0)

(For how those specificity values were calculated, see the resources linked above or the CSS Specificity Calculator).

Because multi-selector rules have two classes added in the generated styles and single-selector rules only have one, the specificity order of the rules changed. This could mean that different styles take precedence than if Svelte didn't scope the styles. In our example, the name's font size would be 24px (as defined by ul li span) instead of 18px (as defined by .name)—the opposite of what you'd expect looking at the raw CSS.

Svelte prevents the specificity order from changing in an interesting way. It keeps track of how many classes are added to each CSS rule, and makes sure each rule has its specificity increased by the same amount. Since .name only had one scoping class applied, Svelte adds a second class to preserve the specificity order:

.name.svelte.svelte (specificity 0-3-0)
ul.svelte li span.svelte (specificity 0-2-3)

By making sure the specificity order remains the same, the scoped CSS produces the same result as the raw CSS.

If you're interested in seeing how this is implemented in the Svelte compiler, see Svelte PR #4146.

Specificity wars

Because Svelte's scoping method increases the specificity of your CSS by adding classes, you may run into issues if you have global styles that you expect to be inherited. For instance, let's say you have the following global styles (e.g., in an external stylesheet):

a {
  color: purple;
}

a:hover {
  color: green;
}

Then, in a Svelte component, you override the default link color:

<a href="https://svelte.dev">Ordinary link</a>
<a class="special-link" href="https://svelte.dev">Exciting link</a>

<style>
  .special-link {
    color: red;
  }
</style>

What color would you expect the link to be on hover?

If you were writing these styles without Svelte's scoping, the link would be red by default (as specified in the component) but green on hover (as specified in the global styles). This is because a:hover is more specific (0-1-1) than .special-link (0-1-0). However, because Svelte added a scoping class, we should really be comparing a:hover to .special-link.svelte, which has a specificity of 0-2-0. Because of this, the .special-link styles also apply when the link is hovered, which may be unexpected.

This problem is exacerbated when Svelte adds multiple scoping classes. If Svelte adds two classes to .special-link, the component styles will be more specific and even more likely to unintentionally override global styles. Unfortunately, there isn't an easy way to work around this behavior. If you want your global styles to apply in this situation, you'll need to find a way to increase their specificity (e.g. by adding !important or doubling up on classes).

There's currently an open Svelte issue objecting to Svelte adding more than one scoping class, though it's not clear how to solve it without re-introducing the original issue around specificity order. There isn't an obvious improvement to be made in the Svelte compiler either—Svelte needs to add something to the CSS rules to make sure they only apply to a single component, and that will increase the specificity. Perhaps native CSS scoping will help, though the spec is still being drafted. Until then, the cost of Svelte's style scoping is some occasional specificity clashes.

Wrapping up

I hope this article helped you understand Svelte's CSS scoping behavior better. Understanding why the compiler makes the decisions it does can help you write better Svelte components and make debugging easier.

If you're interested in going deeper, consider reading the Stylesheet implementation in the Svelte source code—it's surprisingly readable.