Forem: Tan Li Hau

2 ways to pass data into Svelte slots

Tan Li Hau — Wed, 12 May 2021 06:50:55 +0000

We've learned how to use slot in @sveltejs , now let's see how we can pass dynamic data to the slotted contents

<Component>
  <div>i want {dynamic} {data}!</div>
</Component>

This article is a summary from my video from the "Svelte 101" series, "Passing data across slot"

If you prefer video, check it out for a detailed walkthrough!

Watch on YouTube

When you use a slot, data in the slotted content can come from 2 components:

the current component (A)
the component we are using (B)

<!-- filename: A.svelte -->
<B>
  <div>i want {dynamic} {data}!</div>
</B>

1. Passing data from the current component

Passing data from the current component (A) is what we've always do:

define the variable in the script tag
use it

<!-- filename: A.svelte -->
<script>
  let dataFromA = 'dynamic';
</script>

<B>
  <div>i want {dataFromA} {data}!</div>
</B>

2. Passing data from the component you are using

Passing data from the component (B) however, require us to pass the data as props to the slot

<!-- filename: B.svelte -->
<script>
  let dataFromB = 'data';
</script>

<slot dataFromB={dataFromB} />

<!-- or using shorthand: -->
<slot {dataFromB} />

And to receives it, you create what we called a let: binding

<!-- filename: A.svelte -->
<script>
  let dataFromA = 'dynamic';
</script>

<B let:dataFromB>
  <div>i want {dataFromA} {dataFromB}!</div>
</B>

You starts with let: + props name passed to the slot
The props name variable will then be available to your slotted content
The let binding creates a new scope to the elements beneath to access the props variable

You can rename the props name as you need

<!-- filename: A.svelte -->
<script>
  let dataFromA = 'dynamic';
</script>

<B let:dataFromB={somethingElse}>
  <div>i want {dataFromA} {somethingElse}!</div>
</B>

This is especially useful when the prop name shadows the variable from the outer scope, and you want to access both the variables:

<!-- filename: A.svelte -->
<script>
  let data = 'from a';
</script>

<B let:data={dataFromB}>
  <div>data from A: {data}</div>
  <div>data from B: {dataFromB}</div>
</B>

Slot props for named slots

Remember named slots?

You can choose to pass different data for different slotted content!

<!-- filename: B.svelte -->
<script>
  let title = "Passing data to slot";
  let content = "Svelte is fun!";
</script>

<slot name="header" {title}  />
<slot name="body" {content} />

<!-- filename: A.svelte -->
<B>
  <svelte:fragment slot="header" let:title>
    <h1>{title}</h1>
  </svelte:fragment>

  <svelte:fragment slot="body" let:content>
    <div>{content}</div>
  </svelte:fragment>
</B>

Reactive data

Well, the let: binding is not 2-way, (not for now 😓)

To pass data back to the component B, you'll need a callback function

<!-- filename: B.svelte -->
<script>
  let dataFromB = 'data';

  function updateData(newData) {
    dataFromB = newData;
  }
</script>

<slot {dataFromB} {updateData} />

<!-- filename: A.svelte -->
<B let:dataFromB let:updateData>
  <div>i want {dataFromB}!</div>
  <button on:click={() => {
    updateData(123);
  }}>Click Me</button>
</B>

Well, an alternative to callback function would be using a store, however using $ for a store that is not declared at the top-level of the script is not supported yet!

...and the workaround doesn't seem better to me 😓

<!-- filename: A.svelte -->
<B let:dataFromB>
  <!-- ⚠️ Stores must be declared at the top level of the component (this may change in a future version of Svelte) -->
  <div>i want {$dataFromB}!</div>
  <button on:click={() => { $dataFromB = 123; }}>
    Click Me
  </button>
</B>

<!-- Workaround -->
<script>
  import { get } from 'svelte/store';
</script>

<B let:dataFromB>
  <div>i want {get(dataFromB)}!</div>
  <button on:click={() => { dataFromB.set(123); }}>
    Click Me
  </button>
</B>

Reference

Svelte tutorial: Slot props https://svelte.dev/tutorial/slot-props

Explain Svelte slots like I'm five

Tan Li Hau — Thu, 06 May 2021 00:24:33 +0000

If you prefer watching video tutorials, you can watch me explain slots on YouTube

Watch on YouTube

What is a slot?

Just like element, you can pass child element to Components

<div>
  <div>Children</div>
</div>

<Component>
  <div>Children</div>
</Component>

However, the child elements passed to a Component won't show up on the screen, unless explicitly specified using a <slot> element in the Component.

The <slot> element decides where to insert the child elements of the Component

<!-- Component.svelte -->
Some content #1
<slot />
Some content #2

<!-- What you'll see on the DOM -->
Some content #1
<div>Children</div>
Some content #2

You can use the <slot> element multiple times, it just means you want to insert the child elements multiple times in various places

<!-- Component.svelte -->
Some content #1
<slot />
Some content #2
<slot />
<slot />
Some content #3
<slot />
Some content #4

<!-- What you'll see on the DOM -->
Some content #1
<div>Children</div>
Some content #2
<div>Children</div>
<div>Children</div>
Some content #3
<div>Children</div>
Some content #4

Named Slot

But sometimes you want to have some of the child elements inserted at 1 place, and the other in another place....

That's when you want a named slot!

<!-- Component.svelte -->
<slot name="header" />
Some Content here
<slot name="footer" />

To specify which elements go to which named slots, you use the slot="xxx" attribute

<Component>
  <div slot="header">Header</div>
  <div slot="footer">Footer</div>
</Component>

<!-- What you'll see on the DOM -->
<div slot="header">Header</div>
Some Content here
<div slot="footer">Footer</div>

`svelte:fragment`

Unfortunately, if you want multiple elements going into the same slot, specifying the same slot attribute value to more than one elements end up with an error ⚠️😢

<Component>
  <div slot="header">Header #1</div>
  <div slot="header">Header #2</div>
  <div slot="footer">Footer</div>
</Component>

<!-- ⚠️ Duplicate slot name "header" in <Component> -->

That's when you use a <svelte:fragment> to group them!

<Component>
  <svelte:fragment slot="header">
    <div>Header #1</div>
    <div>Header #2</div>
  </svelte:fragment>
  <div slot="footer">Footer</div>
</Component>

<!-- What you'll see on the DOM -->
<div>Header #1</div>
<div>Header #2</div>
Some Content here
<div slot="footer">Footer</div>

Docs: <svelte:fragment>

Slot fallback

Finally, what happens if you didn't pass elements to the Component, but the Component expects something with a slot?

Nothing happens!

<Component>
</Component>

<!-- What you'll see on the DOM -->

Of course, you can always provide a fallback content if nothing is provided 😅

<!-- Component.svelte -->
<slot>Fallback content</slot>

<!-- What you'll see on the DOM -->
Fallback content

Reference

Svelte Tutorial: Slots https://svelte.dev/tutorial/slots
Svelte Tutorial: Slots Fallbacks https://svelte.dev/tutorial/slot-fallbacks
Svelte Tutorial: Named Slots https://svelte.dev/tutorial/named-slots

2 amazing use case of tick() in Svelte that you must know

Tan Li Hau — Wed, 05 May 2021 06:02:15 +0000

According to the tutorial, tick() is a function that returns a promise that resolves as soon as any pending state changes have been applied to the DOM.

But, how is this tick() function useful, why do you need tick(), and when you'll use tick()?

Here's 2 great examples of using tick() that you should't miss out on!

1. Waiting for reactive declared variables to get updated

Say you reactively declared a variable

$: double = value * 2

updating value won't immediately update double.

👉 watch me explained why is that so on youtube:

So, here's how tick() can help. tick() returns a promise that resolves when svelte finishes the upcoming update cycle.

Meaning, by the time tick() resolves, you double is updated too!

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

  let count = 1;
  $: double = count * 2;

  async function increment() {
    count ++;
    // double is still 2

    await tick();

    // 🎉 double is now 4!
    console.log(double); // 4
  }
</script>

2. Waiting for svelte to update the DOM elements

Say you update a variable, svelte updates the DOM asynchronously.

💡 This allow Svelte to batch DOM updates.

However, that means, if you try to read the content / attribute of the DOM element immediately, you are out of luck!

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

  let count = 1;
  let div;

  async function increment() {
    count ++;

    // div still shows '1'
    console.log(div.textContent); // '1'
  }
</script>

<div bind:this={div}>{count}</div>

tick() comes in handy in this case.

So, await for tick(), by the time it resolves, the DOM has updated!

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

  let count = 1;
  let div;

  async function increment() {
    count ++;

    // div still shows '1'
    console.log(div.textContent); // '1'

    await tick();

    // 🎉 div now showing '2'
    console.log(div.textContent); // '2'
  }
</script>

<div bind:this={div}>{count}</div>

📹 Watch me breaking it down in my YouTube video

Bonus

Here's a few more examples when tick() comes in handy!

Querying dynamic content created using `{@html}`

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

  let div;
  let dynamicContent = '<div></div>';

  async function updateContent(newContent) {
    dynamicContent = newContent;

    await tick();

    // div is now updated
    // you can query the new elements
    div.querySelector('div').forEach(doSomething);
  }
</script>

<div bind:this={div}>{@html dynamicContent}</div>

Restoring input cursor position after updating input value

<script>
  import { tick } from 'svelte';
  let value = '';

  async function onInput(event) {
    const input = this;
    let selectionStart = input.selectionStart;
    let selectionEnd = input.selectionEnd;

    value = input.value.toUpperCase();

    await tick();

    input.selectionStart = selectionStart;
    input.selectionEnd = selectionEnd;
  }
</script>

<input on:input={onInput} {value} />

7 Event Modifiers in Svelte You Must Know

Tan Li Hau — Wed, 07 Apr 2021 03:09:42 +0000

This is how you add event listener in Svelte

<script>
  function onClick(event) {
  }
</script>

<button on:click={onClick} />

Under the hood, it is calling addEventListener() from the DOM API.

The addEventListener() takes in 2 parameters, the event type and the listener; and optionally takes in a 3rd parameter, which is the option object.

The option is where you can specify whether to set up the event listener in capture phase, or making it passive. But how do you pass in this option in Svelte?

...

Introducing the Event Modifiers!

Event Modifiers help pass in options to your addEventListener, as well as simplify common patterns in event listener.

Here are the 7 event modifiers you must know!

1. preventDefault

How often you need to call event.preventDefault() to prevent default behavior from the browser? prevent form from submitting, prevent browser disallow drag-and-drop, ...

The preventDefault modifier helps you do that easily.

<script>
  function onClick(event) {}
</script>

<button on:click|preventDefault={onClick} />

This is equivalent of calling event.preventDefault() on the start of the event handler

<script>
  function onClick(event) {}

  function onClickEquivalent(event) {
    event.preventDefault();
    onClick(event);
  }
</script>

<button on:click={onClickEquivalent} />

2. stopPropagation

Have you used event.stopPropagation to prevent event from bubbling up to its parents?

You can easily do that with the stopPropagation modifier!

<script>
  function onClick(event) {}
</script>

<button on:click|stopPropagation={onClick} />

This is equivalent of calling event.stopPropagation() on the start of the event handler

<script>
  function onClick(event) {}

  function onClickEquivalent(event) {
    event.stopPropagation();
    onClick(event);
  }
</script>

<button on:click={onClickEquivalent} />

3. passive

For performance reasons, you may want to specify { passive: true } to indicate to the browser that you will not call event.preventDefault(). This is often used to improve the scrolling performance for scroll event listener

You can do this with the passive modifier

<script>
  function onScroll(event) {}
</script>

<div on:scroll|passive={onScroll} />

This is equivalent of calling addEventListener() with { passive: true }

<script>
  function onScroll(event) {}

  let element;
  onMount(() => {
    element.addEventListener('scroll', onScroll, { passive: true });

    return () => {
      element.removeEventListener('scroll', onScroll, { passive: true });
    }
  });
</script>

<div bind:this={element} />

4. nonpassive

passive: true is great, and Chrome is making them passive by default if you do not pass in the option for passive.

If you want to opt this out, you'll have to specify { passive: false }

which leads to the nonpassive event modifier

<script>
  function onScroll(event) {}
</script>

<div on:scroll|nonpassive={onScroll} />

This is equivalent of calling addEventListener() with { passive: false }

<script>
  function onScroll(event) {}

  let element;
  onMount(() => {
    element.addEventListener('scroll', onScroll, { passive: false });

    return () => {
      element.removeEventListener('scroll', onScroll, { passive: false });
    }
  });
</script>

<div bind:this={element} />

5. once

Sometimes you want the event listener to be called only once. You want to remove the event listener as soon as it's being called.

The once modifier helps you do that

<script>
  function onClick(event) {}
</script>

<button on:click|once={onClick} />

This is equivalent of calling addEventListener() with { once: true }

<script>
  function onClick(event) {}

  let element;
  onMount(() => {
    element.addEventListener('click', onClick, { once: true });

    return () => {
      element.removeEventListener('click', onClick, { once: true });
    }
  });
</script>

<button bind:this={element} />

6. capture

Sometimes, you want to register the event listener for the capturing phase.

You can do it with the capture event modifier

<script>
  function onClick(event) {}
</script>

<button on:click|capture={onClick} />

This is equivalent of calling addEventListener() with { capture: true }

<script>
  function onClick(event) {}

  let element;
  onMount(() => {
    element.addEventListener('click', onClick, { capture: true });

    return () => {
      element.removeEventListener('click', onClick, { capture: true });
    }
  });
</script>

<button bind:this={element} />

7. self

Lastly, you want the event listener to be called only when the event is dispatched from the element itself, and NOT from its children.

You do that with the self event modifier

<script>
  function onClick(event) {}
</script>

<button on:click|self={onClick} />

This is equivalent of checking if the event.target === current element

<script>
  function onClick(event) {}

  let element;
  function onClickEquivalent(event) {
    if (event.target === element) {
      onClick(event);
    }
  }
</script>

<button bind:this={element} on:click={onClickEquivalent} />

Event modifiers can be chained

There are times where you want to apply more than 1 event modifiers, and YES you can do that.

<button on:click|self|stopPropagation|preventDefault={onClick} />

You can chain as many event modifiers as you like, and the order does not matter.

However, by the nature of passive and preventDefault, you can't use them together

<button on:click|passive|preventDefault={onClick} />
<!-- Error: The 'passive' and 'preventDefault' modifiers cannot be used together -->

Do you learn better with video? I've made a video explaining how to add event listeners and cover each of the event modifiers in depth with examples

Notes: The CSS Podcast #027 - "Houdini Series: Typed Object Model"

Tan Li Hau — Sat, 21 Nov 2020 23:14:18 +0000

Podcast

Link to the Podcast

Notes

CSS Typed Object Model (Typed OM)

CSS Typed OM API allow manipulating CSS styles through a typed JS representation rather than a simple string.
Provide performance win. Browser understands the structured JS representation and no longer needs to parse CSS string from scratch.

const div = document.createElement('div');

// browser needs to parse the string to understand and use it
div.style.height = '5px';

// browser understands and use the value as 5px
div.style.height = CSS.px(5);

Built-in error handling. You can't provide invalid value to a type.

div.attributeStyleMap.set('color', CSS.px(10))
// TypeError: Failed to set, invalid type for property

Rather than manipulating raw string, developer can create / transform CSS in a meaningful object

const _5px = CSS.px(5); // 5px
const _15px = _5px.add(CSS.px(10)); // 15px;

const div = document.createElement('div');
div.style.height = _15px;
// <div style="height: 15px;"></div>

API based on functional programming concept
To check browser support Typed OM, currently (21 Nov 2020) supported in Safari Tech Preview & Chromium

// checking browser support
if (window.CSS && CSS.number) {
  // 😍 browser supports Typed OM!
}

computedStyleMap

<script>
  const element = document.querySelector('#app');

  console.log(element.computedStyleMap().get('font-size'));
  // Specification: CSSUnitValue { value: 2, unit: 'rem' }
  // Chrome: CSSUnitValue { value: 32, unit: 'px' }

  console.log(window.getComputedStyle(element).fontSize);
  // "32px"
</script>

<div id="app" style="font-size: 2rem;"></div>

attributeStyleMap

parse, modify inline styles

<script>
  const element = document.querySelector('#app');

  const inlineStyles = element.attributeStyleMap;

  console.log(inlineStyles.get('font-size'));
  // CSSUnitValue { value: 2, unit: 'rem' }

  inlineStyles.set('height', CSS.px(10));
  // <div id="app" style="font-size: 2rem; height: 10px;"></div>

  inlineStyles.clear();
  // <div id="app" style=""></div>

  inlineStyles.append('background-image', 'linear-gradient(yellow, green)');
  inlineStyles.append('background-image', 'linear-gradient(to bottom, blue, red)');
  // <div id="app" 
  //   style="background-image: linear-gradient(yellow, green), 
  //                      linear-gradient(to bottom, blue, red)"></div>

  inlineStyles.delete('background');
  // <div id="app" style=""></div>

  inlineStyles.has('opacity');
  // false
</script>

<div id="app" style="font-size: 2rem;"></div>

<script>
  // `attributeStyleMap` only gets inline style
  console.log(element.attributeStyleMap.get('color'));
  // null
  console.log(element.computedStyleMap().get('color'));
  // CSSStyleValue { /* red */ }
</script>

<div id="app" style="font-size: 2rem;"></div>

<style>
  #app {
    color: red;
  }
</style>

Types of CSSStyleValue

CSSImageValue
CSSKeywordValue
CSSNumericValue
CSSPositionValue
CSSTransformValue
CSSUnparsedValue

create CSSStyleValue

CSSStyleValue.parse('font-size', '32px');
// CSSUnitValue { value: 2, unit: 'px' }

CSSStyleValue.parse('transform', 'translate3d(10px, 20px, 30px) scale(1.5)');
/* 
CSSTransformValue {
  0: CSSTranslate {
    is2D: false
    x: CSSUnitValue { value: 10, unit: 'px' }
    y: CSSUnitValue { value: 20, unit: 'px' }
    z: CSSUnitValue { value: 30, unit: 'px' }
  }
  1: CSSScale {
    is2D: true
    x: CSSUnitValue { value: 1.5, unit: 'number' }
    y: CSSUnitValue { value: 1.5, unit: 'number' }
    z: CSSUnitValue { value: 1, unit: 'number' }
  }
}
*/

CSSImageValue

does not cover linear-gradient

CSSKeywordValue

display: none, none is a CSSKeywordValue

CSSStyleValue.parse('display', 'none');
// CSSKeywordValue { value: 'none' }
const keywordValue = new CSSKeywordValue('flex');
// CSSKeywordValue { value: 'flex' }
keywordValue.value;
// 'flex'

CSSNumericValue

CSSNumericValue has a few subclasses, eg: CSSUnitValue, CSSMathValue

// Convert units
CSS.px(48).to('in')
// CSSUnitValue { value: 0.5, unit: 'in' }

CSS.px(48).to('rem')
// Error
// Cannot transform absolute unit to relative unit

CSSMathValue

CSSMathNegate, CSSMathMin, CSSMathMax, CSSMathSum, CSSMathProduct, CSSMathInvert

new CSSMathSum(CSS.px(5), CSS.px(10)); // 15px

div.attributeStyleMap.set('width', new CSSMathMax(CSS.rem(10), CSS.px(30)));
// <div style="width: max(10rem, 30px)"></div>

CSSPositionValue

const position = new CSSPositionValue(CSS.px(20), CSS.px(50))
position.x; // CSSUnitValue { value: 20, unit: 'px' }
position.y; // CSSUnitValue { value: 50, unit: 'px' }

CSSTransformValue

CSSTranslate, CSSScale, CSSRotate, CSSSkew, CSSSkewX, CSSSkewY, CSSPerspective, CSSMatrixComponent

const transformValue = CSSStyleValue.parse('transform', 'translate3d(10px, 20px, 30px) scale(1.5)');

// iterate through each transformation
for (const transform of transformValue) {
  console.log(transform);
}
// CSSTranslate { ... }
// CSSScale { ... }

// get DOMMatrix out of the transformValue
transformValue.toMatrix();
// DOMMatrix { a: 1.5, b: 0, c: 0, ... }

CSSUnparsedValue

CSSCustomProperty, that is not Houdini Property
the value is parsed as string

<script>
  const element = document.querySelector('#app');

  element.attributeStyleMap.get('--length');
  // CSSUnparsedValue { 0: 3px }
</script>
<div id="app" style="--length: 3px;">

References

Specifications https://www.w3.org/TR/css-typed-om-1/
MDN https://developer.mozilla.org/en-US/docs/Web/API/CSS_Typed_OM_API
caniuse attributeStyleMap https://caniuse.com/mdn-api_element_attributestylemap
caniuse computedStyleMap https://caniuse.com/mdn-api_element_computedstylemap

Notes: The CSS Podcast #026 - "Houdini Series: Properties & Values"

Tan Li Hau — Sun, 15 Nov 2020 07:29:50 +0000

Podcast

Link to the Podcast

Notes

CSS Houdini

Umbrella term that covers a set of low-level APIs that exposes parts of the CSS rendering engine
Give developers access to CSS Object Model.
Enable developers to extends CSS by hooking into the styling and layout processes
No need to wait for browsers to implement CSS primitives
Write your own painting and layout algorithm using worklet
Write less JS dependencies and polyfills, allow users write true CSS polyfills that browser can better understand
Allow more semantic CSS, allow performance optimisations in how the browser actually reads and parses CSS
Allow typechecking CSS

Properties and Values API

create rich and typed property
error free, error gracefully, fallback to initial value
provide semantic meaning to the variable
custom property values are no longer a string
allow you to interpolate the value as you transition from 1 value to another
be known and passed to the function as accepted and identified parameter
cascade still applies

2 ways to register houdini custom properties

CSS.registerProperty in JS
@property in CSS

CSS.registerProperty({
  name: '--colorPrimary',  // start with `--`
  syntax: '<color>',       // syntax value
  initialValue: 'magenta', // initial value if not defined
  inherits: false,         // inherit from parent
});

/* Included in Chromium 85 */
@property --colorPrimary {
  syntax: '<color>';      /* syntax value */
  initial-value: magenta; /* does not need to be a string */
  inherits: false;        /* inherit from parent */
}

enforces it the --colorPrimary to be a value of color
if it is not a color, will error gracefully by fallback to its initial value
trying to see the console, but haven't see it in the console yet

Syntax

CSS definition syntax https://web.dev/at-property/#syntax
<length>, eg: 1px, 2rem, 3vw
<percentage>, eg: 4%
- in linear-gradient
<length-percentage>
- superset of length + percentage
- you can use calc() of mixing percentage and length, eg: calc(100% - 35px)
<angle>, eg: 1deg
- in hsl, conic-gradient
<time>, eg: 1s
- in animation, transition
<resolution> , eg: 300dpi
- in media query
<integer>, positive / negative whole number
- in z-index, grid-row
<number>
<color>
<transform-function>, 2d / 3d transform function
<custom-ident>
- eg: animation-name

Multipliers

Component value multipliers

<length>+, length can appear one or more times, eg: "1px 2px 3px"
<length>#, length appear one or more times with comma separated, eg: "1px, 2px 3px"

Combinators

Component value combinators

|, eg: <percentage> | <length>, must be either percentage or length, and appear only once

References

Contributing to Svelte - Implement {#key}

Tan Li Hau — Sun, 27 Sep 2020 08:00:00 +0000

Background

Unlike the other contributing to Svelte posts [1] [2], which I wrote it while implementing the fix, describing as detailed as possible, today I am going to share the process of how I implemented the {#key} block retrospectively.

The implementation of the {#key} block is much simpler, relative to {#if}, {#await} or {#each}. And I believe the process of implementing the {#key} block helps paint the pratical side of "The Svelte Compiler Handbook" or my "Looking into the Svelte compiler" talk.

The motivation

The idea of {#key} block starts with the feature request 2 years ago (yea, it's that long) for the ability to key a non-each component, GitHub issue #1469.

To key a component, is to force recreation of the component when the key changes.

And you see this ability of destroying and creating new components when using {#each} with key:

<script>
  let data = [{ id: 1, name: 'alice' }];
  function update() {
    data = [{ id: 2, name: 'bob' }];
  }
</script>
{#each data as item (item.id)}
  <div>{ item.name }</div>
{/each}

REPL

When we call the function update, we removed alice from the data and we added bob. The net effect is still having a list of 1 item. However, instead of reusing the 1 <div /> by updating { item.name } to "bob", Svelte removes and destroys the <div /> and create a new <div /> for bob. This is because of the key we specified to the {#each} block. Svelte will not reuse the <div /> because it was created with a different key.

One of the benefits of having a key for {#each} item is to be able to add transition to the item correctly. Without a key to identify which item is added / removed, the transiion on a {#each} list will always applied to the last item, when the list grows or shrinks in length.

Try with and without the key in this REPL to see the importance of having a key.

This is similar to the key attribute of React, if you are familiar with React. Check this out on how to remount a component with the key attribute in React.

However, the ability of having to key an element / component only exist for the {#each} block. To workaround the constraint, it's common to use the "1-item keyed-each hack":

{#each key as k (k)}
  <div />
{/each}

The <div /> will be recreated if the key has changed.

Transitions for reactive data change

Another commonly brought up request, to be able to apply transition: to an element when a reactive data changes (GitHub issue #5119):

<script>
  import { fade } from 'svelte/transition'
  let count = 0;
  const handleClick = () => count +=1
</script>

<button on:click={handleClick}>Click me</button>

<p>You clicked <strong transition:fade>{count}</strong> times</p>

This is another facet of the same issue.

We need an ability to transition the old element out, and transition a new element in when a data, or a key changes.

A workaround, again, is to use the "1-item keyed-each hack":

<script>
  import { fade } from 'svelte/transition'
  let count = 0;
  const handleClick = () => count +=1
</script>

<button on:click={handleClick}>Click me</button>

<p>You clicked
  {#each [count] as count (count)}
    <strong transition:fade>{count}</strong>
  {/each}
 times</p>

So the proposal of the feature request was to have a {#key} block:

<p>You clicked
  {#key count}
    <strong transition:fade>{count}</strong>
  {/key}
 times</p>

I've seen this issue months ago, and I passed the issue. I didn't think I know good enough to implement a new logic block. However, the issue recently resurfaced as someone commented on it recently. And this time, I felt I am ready, so here's my journey of implementing the {#key} block.

The implementation

As explained in "The Svelte Compiler Handbook", the Svelte compilation process can be broken into steps:

Parsing
Tracking references and dependencies
Creating code blocks & fragments
Generate code

Of course, that's the steps that we are going to work on as well.

Parsing

The actual parsing starts here in src/compiler/parse/index.ts:

let state: ParserState = fragment;

while (this.index < this.template.length) {
  state = state(this) || fragment;
}

There are 4 states in the parser:

fragment - in this state, we check the current character and determine which state we should proceed to
tag - we enter this state when we encounter < character. In this state, we are going to parse HTML tags (eg: <p>), attributes (eg: class) and directives (eg: on:).
mustache - we enter this state when we encounter { character. In this state, we are going to parse expression, { value } and logic blocks {#if}
text - In this state, we are going to parse texts that are neither < nor {, which includes whitespace, newlines, and texts!

To be able to parse the {#key} block, we are going to take a look at the mustache state function.

The {#key} block syntax is similar to {#if} without else, we take in an expression in the opening block and that's all:

{#key expression}
   <div />
{/key}

<!-- similar to -->
{#if expression}
  <div />
{/if}

So over here, when we encounter a {#, we add a case to check if we are starting a {#key} block:

// ...
} else if (parser.eat(#)) {
  // if {#if foo}, {#each foo} or {#await foo}
  let type;

  if (parser.eat('if')) {
    type = 'IfBlock';
  } else if (parser.eat('each')) {
    type = 'EachBlock';
  } else if (parser.eat('await')) {
    type = 'AwaitBlock';
+  } else if (parser.eat('key')) {
+    type = 'KeyBlock';
  } else {
    parser.error({
      code: `expected-block-type`,
-      message: `Expected if, each or await`
+      message: `Expected if, each, await or key`
    });
  }

Similarly, for closing block {/, we are going to make sure that {#key} closes with {/key}:

if (parser.eat('/')) {
  let block = parser.current();
  let expected;
  // ...
  if (block.type === 'IfBlock') {
    expected = 'if';
  } else if (block.type === 'EachBlock') {
    expected = 'each';
  } else if (block.type === 'AwaitBlock') {
    expected = 'await';
+  } else if (block.type === 'KeyBlock') {
+    expected = 'key';
  } else {
    parser.error({
      code: `unexpected-block-close`,
      message: `Unexpected block closing tag`
    });
  }

The next step is to read the JS expression. Since all logic blocks, {#if}, {#each} and {#await} will read the JS expression next, it is no different for {#key} and it is already taken care of:

parser.require_whitespace();

// read the JS expression
const expression = read_expression(parser);

// create the AST node
const block: TemplateNode = {...};

parser.allow_whitespace();

// other logic blocks specific syntax
if (type === 'EachBlock') {
  // {#each} block specific syntax for {#each list as item}
  // ...
}

So, let's move on to the next step!

Tracking references and dependencies

If you noticed in the previous step, the type name we created for {#key} block is called KeyBlock.

So, to keep the name consistent, we are going to create a KeyBlock class in src/compiler/compile/nodes/KeyBlock.ts:

import Expression from './shared/Expression';
import map_children from './shared/map_children';
import AbstractBlock from './shared/AbstractBlock';

export default class KeyBlock extends AbstractBlock {
  // for discriminant property for TypeScript to differentiate types
  type: 'KeyBlock';

  expression: Expression;

  constructor(component, parent, scope, info) {
    super(component, parent, scope, info);

    // create an Expression instance for the expression
    this.expression = new Expression(component, this, scope, info.expression);

    // loop through children and create respective node instance
    this.children = map_children(component, this, scope, info.children);

    // simple validation: make sure the block is not empty
    this.warn_if_empty_block();
  }
}

I've added comments annotating the code above, hopefully it's self-explanatory.

A few more points:

info is the AST node we got from the parsing.
the class Expression is constructed with the JavaScript AST of the expression and it is where we traverse the AST and marked the variables within the expression as referenced: true.
map_children is used to map the children of the KeyBlock AST node to the compile node.

Pardon for my lack of "appropriate" naming to differentiate the nodes in the Svelte codebase.

Throughout the Svelte compilation process, the node is transformed one to another, which in every step of the transformation, new analysis is performed, and new information are added.

Here, I am going to call:

the node resulting from the parser: AST node

the node created by the Component, which extends from compiler/compile/nodes/shared/Node.ts: compile node (because they are stored in the compile folder)

the node created by the Renderer, which extends from compiler/compile/render_dom/wrappers/shared/Wrapper.ts: render-dom Wrapper (also because they are stored in the render_dom/wrappers folder)

If you managed to keep up so far, you may be sensing where we are heading next.

We need to add KeyBlock into map_children:

// src/compiler/compile/nodes/shared/map_children.ts
function get_constructor(type) {
  switch (type) {
    case 'AwaitBlock':
      return AwaitBlock;
    case 'Body':
      return Body;
    // ...
    // 👇👇👇👇
    case 'KeyBlock':
      return KeyBlock;
    // ...
  }
}

Also, we need to add KeyBlock as one of the INode type for TypeScript:

// src/compiler/compile/nodes/interfaces.ts
export type INode =
  | Action
  | Animation
  // ...
  // 👇👇👇👇
  | KeyBlock;
// ...

And now, let's move on to implementing a render-dom Wrapper for KeyBlock.

Creating code blocks & fragments

At this point, we need to decide how the compiled JS should look like, it's time for us to reverse-compile Svelte in your head!

If you've read my Compile Svelte in your head (Part 4), you've seen how we create a different create_fragment function for each of the logic branches, so we can control the content within a logic branch as a whole.

Similarly, we can create a create_fragment function for the content of the {#key}, then we can control when to create / mount / update / destroy the content.

function create_key_block(ctx) {
  // instructions to create / mount / update / destroy inner content of {#key}
  return {
    c() {},
    m() {},
    p() {},
    d() {},
  };
}

To use the create_key_block:

const key_block = create_key_block(ctx);
// create the elements for the {#key}
key_block.c();

// mount the elements in the {#key}
key_block.m(target, anchor);

// update the elements in the {#key}
key_block.p(ctx, dirty);

// destroy the elements in the {#key}
key_block.d(detaching);

// intro & outro the elements in the {#key}
transition_in(key_block);
transition_out(key_block);

The next thing to do, is to place these statements in the right position:

function create_fragment(ctx) {
  // init
  let key_block = create_key_block(ctx);

  return {
    c() {
      // create
      key_block.c();
    },
    m(target, anchor) {
      // mount
      key_block.m(target, anchor);
    },
    p(ctx, dirty) {
      // update
      key_block.p(ctx, dirty);
    },
    i(local) {
      // intro
      transition_in(key_block);
    },
    o(local) {
      // outro
      transition_out(key_block);
    },
    d(detaching) {
      // destroy
      key_block.d(detaching);
    },
  };
}

Now, the most important piece of the {#key} block, the logic to

check if the expression has changed
if so, recreate the elements inside the {#key} block

function create_fragment(ctx) {
  // we store the previous key expression value
  let previous_key = value_of_the_key_expression;
  // ...
  return {
    // ...
    p(ctx, dirty) {
      if (
        // if the any variables within the key has changed, and
        dirty & dynamic_variables_in_key_expression &&
        // if the value of the key expression has changed
        previous_key !== (previous_key = value_of_the_key_expression)
      ) {
        // destroy the elements
        // detaching = 1 (true) to remove the elements immediately
        key_block.d(1);
        // create a new key_block
        key_block = create_key_block(ctx);
        key_block.c();
        // mount the new key_block
        key_block.m(...);
      } else {
        // if the key has not changed, make sure the content of {#key} is up to date
        key_block.p();
      }
    }
    // ...
  }
}

If there is transition in the content of the key_block, we need extra code for the transition:

// instead of key_block.d(1);
group_outros();
transition_out(key_block, 1, 1, noop);
check_outros();

// before key_block.m(...)
transition_in(key_block);

I am going to gloss over the details of how outros / intros work, we will cover them in the later parts of "Compile Svelte in your head", so let's assume these code are up for the job.

Now we have done the reverse-compile Svelte in your head, let's reverse the reverse, and write the render code for Svelte {#key} block.

Here are some setup code for the render-dom Wrapper for {#key}:

export default class KeyBlockWrapper extends Wrapper {
  // ...
  // the `key_block` variable
  var: Identifier = { type: 'Identifier', name: 'key_block' };

  constructor(renderer: Renderer, block: Block, parent: Wrapper, node: EachBlock, strip_whitespace: boolean, next_sibling: Wrapper) {
    super(renderer, block, parent, node);

    // deoptimisation, set flag indicate the content is not static
    this.cannot_use_innerhtml();
    this.not_static_content();

    // get all the dynamic variables within the expression
    // useful for later
    this.dependencies = node.expression.dynamic_dependencies();

    // create a new `create_fragment` function
    this.block = block.child({
      comment: create_debugging_comment(node, renderer.component),
      name: renderer.component.get_unique_name('create_key_block'),
      type: 'key',
    });
    renderer.blocks.push(block);

    // create render-dom Wrappers for the children
    this.fragment = new FragmentWrapper(renderer, this.block, node.children, parent, strip_whitespace, next_sibling);
  }
  render(block: Block, parent_node: Identifier, parent_nodes: Identifier) {
    // NOTE: here is where we write the render code
  }
}

A few more points:

the block in the render method is the current create_fragment function that the {#key} block is in; this.block is the new create_fragment function that we created to put the content of the {#key} block
- we named the new create_fragment function "create_key_block"
- to make sure there's no conflicting names, we use renderer.component.get_unique_name()
All render-dom wrappers has a property named var, which is the variable name referencing the element / block to be created by the render-dom wrapper.
- the var name will be deconflicted by the Renderer

Now, let's implement the render method.

Firstly, render the children into this.block:

render(block: Block, parent_node: Identifier, parent_nodes: Identifier) {
  this.fragment.render(
    this.block,
    null,
    (x`#nodes` as unknown) as Identifier
  );
}

We pass in null as parent_node and x`#nodes` as parent_nodes to indicate that the children will be rendered at the root of the this.block.

If I am implementing the render method of an Element render-dom Wrapper, and currently rendering the <div> in the following code snippet:

<div>
  <span />
</div>

then I will render the <span /> with:

spanWrapper.render(
  block,
  this.var, // div's var
  x`${this.var.name}.childNodes`, // div.childNodes
);

so the <span /> will be inserted into the current <div /> and hydrate from the <div />'s childNodes.

Next, I am going to insert code into each of the fragment methods:

// let key_block = create_key_block(ctx);
block.chunks.init.push(
  b`let ${this.var} = ${this.block.name}(#ctx)`
);

// key_block.c();
block.chunks.create.push(b`${this.var}.c();`);

// key_block.m(...);
block.chunks.mount.push(
  b`${this.var}.m(${parent_node || "#target"}, ${parent_node ? "null" : "#anchor"});`
);

// key_block.p(...);
block.chunks.update.push(
  b`${this.var}.p(#ctx, #dirty);`
);

// key_block.d(...);
block.chunks.destroy.push(b`${this.var}.d(detaching)`);

A few more points:

we push the code into respective methods of the block, eg: init, create, mount, ...
we use tagged templates, b`...` to create a JavaScript AST node. The b tag function allow us to pass in JavaScript AST node as placeholder, so that is very convenient.
- You can check out more about the b tag function from code-red

Now, to implement the dirty checking, we use this.dependencies

const is_dirty = this.renderer.dirty(this.dependencies);

To determine whether our expression value has changed, we are going to compute the expression and compare it with previous_key and determine whether it has changed.

Here's a recap of the compiled code that we've come up previously:

// we store the previous key expression value
let previous_key = value_of_the_key_expression;
// ...
// if the value of the key expression has changed
previous_key !== (previous_key = value_of_the_key_expression)

We start with declaring the variable, previous_key:

const previous_key = block.get_unique_name('previous_key');
const snippet = this.node.expression.manipulate(block);
block.add_variable(previous_key, snippet);

expression.manipulate(block) will convert the expression to refer to the ctx variable, for example:

human.age + limit
// into something like
ctx[0].age + ctx[2]

Next we are going to compare the new value and assign it to previous_key after that.

const has_change = x`${previous_key} !== (${previous_key} = ${snippet})`

And to combine all of these, we have:

block.chunks.update.push(b`
  if (${is_dirty} && ${has_change}) {
    ${this.var}.d(1);
    ${this.var} = ${this.block.name}(#ctx);
    ${this.var}.c();
    ${this.var}.m(${this.get_update_mount_node(anchor)}, ${anchor});
  } else {
    ${this.var}.p(#ctx, #dirty);
  }
`);

We are using the anchor when we are mounting the new key_block, you can check out Compile Svelte in your head Part 4: the extra text node, explaining why we need the anchor node, and here is how the anchor node being computed:

const anchor = this.get_or_create_anchor(block, parent_node, parent_nodes);

It could be the next sibling, or it could be a new empty() text node created.

Finally, if the content has transition, we need to add code for the transition as well:

const has_transitions = !!(this.block.has_intro_method || this.block.has_outro_method);
const transition_out = b`
  @group_outros();
  @transition_out(${this.var}, 1, 1, @noop);
  @check_outros();
`;
const transition_in = b`
  @transition_in(${this.var});
`;

Where to place them? Well, I'll leave that as your exercise to figure that out. 😉

Creating code for SSR

For SSR, it is much simpler than for the dom. {#key} block has no special meaning in SSR, because, you will only render once in SSR:

import KeyBlock from '../../nodes/KeyBlock';
import Renderer, { RenderOptions } from '../Renderer';

export default function(node: KeyBlock, renderer: Renderer, options: RenderOptions) {
    renderer.render(node.children, options);
}

☝️ That's all the code we need for SSR. We are rendering the children, passing down the options, and add no extra code for the {#key} block.

Generate code

Well, everything in this step is set up generic enough to handle most use case.

So, nothing to change here. 🤷‍♂️

A few other implementation consideration

What if the expression in the {#key} block is not dynamic, do we give warnings? or optimise the output?
How will <svelte:options immutable={true}> affect the code output?

The testing

You've seen me implementing test cases in the previous "Contributing to Svelte" articles [1] [2], here I am going to skip showing the implementation of the test cases, and probably point out some thoughts I had when coming up with tests:

Happy path: changing the key expression should recreate the content
Happy path: Transition when recreating the content should work ✨
Possible edge case: Changing variables other than the key expression should not recreate the content in {#key}

   <script>
     let reactive1;
     let reactive2;
     let key;
   </script>

   {#key key}
      {key} {reactive1}
   {/key}

   {reactive2}

Possible edge case: Changing the variables within the key expression but the result value of the key expression stay the same

   <script>
      let a = 1;
      let b = 2;
      function update() {
        a = 2;
        b = 1;
      }
   </script>
   {#key a + b}
      <div />
   {/key}

Closing Notes

You can read the Pull Request #5397 to read the final implementation.

If you wish to learn more about Svelte, follow me on Twitter.

If you have anything unclear about this article, find me on Twitter too!

Compile Svelte in your head ({#if})

Tan Li Hau — Tue, 22 Sep 2020 08:00:00 +0000

In this article, we are going to cover our first logic block, the if block.

To make sure we are on the same page, let's first explain how if block works.

The `{#if}` block

To render content conditionally, you can wrap it with the {#if} block:

{#if condition}
  <div>Conditionally rendered content</div>
{/if}

If the condition is truthy, you will see the <div>Conditionally rendered content</div>, otherwise you will see nothing.

Like JavaScript, you can use else and else if in Svelte to test multiple conditions too:

{#if condition_a}
  <div>Rendered due to condition_a</div>
{:else if condition_b}
  <div>Rendered due to condition_b</div>
{:else}
  <div>Otherwise</div>
{/if}

You can visit Svelte's interactive tutorial to learn more about the {#if} logic block.

The Vanilla JS

So how do we implement an {#if} logic without any framework?

As mentioned in the Part 1 of the series, we've seen how we can create elements without framework help.

Implementating the if block

Implementing an {#if} logic block can be as follow:

function createElementsIfConditionA() {
  // code to create `<div>Rendered due to condition_a</div>`
}
function createElementsIfConditionB() {
  // code to create `<div>Rendered due to condition_b</div>`
}
function createElementsElse() {
  // code to create `<div>Otherwise</div>`
}

function createIfBlock() {
  if (condition_a) {
    createElementsIfConditionA();
  } else if (condition_b) {
    createElementsIfConditionB();
  } else {
    createElementsElse();
  }
}

The condition_a and condition_b could be dynamic, which means if the condition changed, we may need to call createIfBlock again.

But before that, we need to remove the elements that we created previously. This depends on which conditions were met previously, and which elements were created previously.

So, let's store that information in a variable:

function destroyElementsIfConditionA() {
  // code to destroy `<div>Rendered due to condition_a</div>`
}
function destroyElementsIfConditionB() {
  // code to destroy `<div>Rendered due to condition_b</div>`
}
function destroyElementsElse() {
  // code to destroy `<div>Otherwise</div>`
}

let previousDestroy;
function getPreviousDestroy() {
  if (condition_a) {
    previousDestroy = destroyElementsIfConditionA;
  } else if (condition_b) {
    previousDestroy = destroyElementsIfConditionB;
  } else {
    previousDestroy = destroyElementsElse;
  }
}

function createIfBlock() {
  // ...
  getPreviousDestroy();
}

So, if conditions changed, we destroy the previously created elements, and create a new one:

function updateIfBlock() {
  // if `condition_a` or `condition_b` changed
  if (conditionChanged) {
    previousDestroy();
    createIfBlock();
  }
}

However, if the condition does not change, but the content within the if block changes, for example, value_a, value_b or value_else change in the following code:

{#if condition_a}
  <div>{ value_a }</div>
{:else if condition_b}
  <div>{ value_b }</div>
{:else}
  <div>{ value_else }</div>
{/if}

Then we need to know how to update the elements as well:

function updateElementsIfConditionA() {
  // code to update `<div>{ value_a }</div>`
}
function updateElementsIfConditionB() {
  // code to update `<div>{ value_b }</div>`
}
function updateElementsElse() {
  // code to update `<div>{ value_else }</div>`
}

function updateIfBlock() {
  // if `condition_a` or `condition_b` changed
  if (conditionChanged) {
    previousDestroy();
    createIfBlock();
  } else {
    if (condition_a) {
      updateElementsIfConditionA();
    } else if (condition_b) {
      updateElementsIfConditionB();
    } else {
      updateElementsElse();
    }
  }
}

Finally to destroy the elements if we want to unmount the whole {#if} block, we can use previousDestroy, since it will be based on the conditions that the elements were created with:

function destroyIfBlock() {
  previousDestroy();
}

Here we have createIfBlock, updateIfBlock and destroyIfBlock. It looks unwieldy, as the if (condition) logic is scattered across createIfBlock, getPreviousDestroy and updateIfBlock.

So, let's refactor this. Let's shift code around to make it cleaner. ✨

Refactor the code

For each of the logic branch, we have functions to create, update and destroy its elements. For the first condition branch, we have:

createElementsIfConditionA
updateElementsIfConditionA
destroyElementsIfConditionA

It seems like we can employ some sort of Strategy Pattern over here.

We can group the operations for each condition branch together, where each operation has the same interface, { create(){}, update(){}, destroy(){} } :

const operationConditionA = {
  create: createElementsIfConditionA,
  update: updateElementsIfConditionA,
  destroy: destroyElementsIfConditionA,
};
const operationConditionB = {
  create: createElementsIfConditionB,
  update: updateElementsIfConditionB,
  destroy: destroyElementsIfConditionB,
};
const operationConditionElse = {
  create: createElementsElse,
  update: updateElementsElse,
  destroy: destroyElementsElse,
};

Now, we choose the operation based on the condition, since they have the same interface, they should be able to be used interchangeably:

function getOperation() {
  if (condition_a) {
    return operationConditionA;
  } else if (condition_b) {
    return operationConditionB;
  } else {
    return operationConditionElse;
  }
}

Here, we can rewrite our createIfBlock, updateIfBlock and destroyIfBlock:

let currentOperation = getOperation();

function createIfBlock() {
  currentOperation.create();
}

function updateIfBlock() {
  const previousOperation = currentOperation;
  currentOperation = getOperation();
  // if (conditionChanged)
  if (currentOperation !== previousOperation) {
    previousOperation.destroy();
    currentOperation.create();
  } else {
    currentOperation.update();
  }
}

function destroyIfBlock() {
  currentOperation.destroy();
}

To determine whether the condition changed, we can compute the operation and compare it with the previous operation to see if it has changed.

The Compiled JS

Now let's take look at how Svelte compiles {#if} into output JavaScript.

<script>
    let loggedIn = false;

    function toggle() {
        loggedIn = !loggedIn;
    }
</script>

{#if loggedIn}
    <button on:click={toggle}>
        Log out
    </button>
{:else}
    <button on:click={toggle}>
        Log in
    </button>
{/if}

Svelte REPL

The output code:

/* App.svelte generated by Svelte v3.25.1 */
// ...
function create_else_block(ctx) {
  // ...
  return {
    c() { /* ... */ },
    m(target, anchor) { /* ... */ },
    p: noop,
    d(detaching) { /* ... */ },
  };
}

// (9:0) {#if loggedIn}
function create_if_block(ctx) {
  // ...
  return {
    c() { /* ... */ },
    m(target, anchor) { /* ... */ },
    p: noop,
    d(detaching) { /* ... */ },
  };
}

function create_fragment(ctx) {
  // ...
  function select_block_type(ctx, dirty) {
    if (/*loggedIn*/ ctx[0]) return create_if_block;
    return create_else_block;
  }

  let current_block_type = select_block_type(ctx, -1);
  let if_block = current_block_type(ctx);

  return {
    c() {
      if_block.c();
      if_block_anchor = empty();
    },
    m(target, anchor) {
      if_block.m(target, anchor);
      insert(target, if_block_anchor, anchor);
    },
    p(ctx, [dirty]) {
      if (current_block_type === (current_block_type = select_block_type(ctx, dirty)) && if_block) {
        if_block.p(ctx, dirty);
      } else {
        if_block.d(1);
        if_block = current_block_type(ctx);

        if (if_block) {
          if_block.c();
          if_block.m(if_block_anchor.parentNode, if_block_anchor);
        }
      }
    },
    i: noop,
    o: noop,
    d(detaching) {
      if_block.d(detaching);
      if (detaching) detach(if_block_anchor);
    },
  };
}

Some observations:

Observation 1: If you compare the Svelte's compiled output and the JS code we came out earlier, you may see some resemblance:

For each logic branch, we have a create_fragment function, which in this case is create_else_block and create_if_block. As explain in the previous article, these functions return an instruction manual on how to build the DOM fragment for each logic branch.

This is similar to the operations we discussed earlier, eg: operationConditionA, operationConditionB and operationConditionElse.

To determine which create_fragment function to use, we have the select_block_type function.

This is similar to the getOperation we discussed earlier.

We then initialise the fragment for the current condition branch,

let current_block_type = select_block_type(ctx, -1);
let if_block = current_block_type(ctx);

Now we can:
- create if_block.c()
- mount if_block.m(target, anchor)
- update if_block.p(ctx, dirty)
- destroy if_block.d(detaching)

elements for the {#if} block.

In the p (u_p_date) method, we check if the current_block_type has changed, if not, then we call if_block.p(ctx, dirty) to update as necessary.

If there's change, then we destroy if_block.d(1) the previous elements, create a new fragment based on the current_block_type, then create and mount the elements via if_block.c() and if_block.m(...).

This is similar to how we call previousOperation.destroy() and currentOperation.create() or currentOperation.update().

Observation 2: There's a if_block_anchor inserted after the if_block

if_block_anchor = empty()

empty() creates an empty text node.

// https://github.com/sveltejs/svelte/blob/v3.25.1/src/runtime/internal/dom.ts#L56-L58
export function empty() {
  return text('');
}

The if_block_anchor is then used when mounting the if_block in the u_p_date method.

if_block.m(if_block_anchor.parentNode, if_block_anchor)

So what is this extra empty text node for?

The extra text node

When we update the {#if} block and notice that we need to change the fragment block type, we need to destroy the elements created previously, and insert newly created elements.

When we insert the new elements, we need to know where to insert them. The insertBefore API allow us to specify which node the elements should be inserted before. So now it begs the question, which node?

The answer depends on the position {#if} block is written in the component. There are 4 possible scenarios:

1. There's an element right after the {#if} block

{#if condition}
  <div />
{/if}
<span />

Svelte REPL

You'll see that

Svelte does not create the extra text node
Instead, Svelte uses the <span /> node instead

if_block.m(span.parentNode, span)

When the {#if} condition changes, {#if} block will replace and insert new elements before the <span /> element.

2. {#if} block is the last child, {#if} block has a parent

<div>
  {#if condition}
    <div />
  {/if}
</div>

Svelte REPL

You'll see that

Svelte does not create the extra text node
Instead, Svelte inserts the {#if} block into the parent node, <div /> and insert before null. (If you pass null to insertBefore, it will append the element as the last child)

if_block.m(div, null);

When the {#if} condition changes, {#if} block will replace and insert new elements as the last children of the parent <div /> element.

3. {#if} block is the last child, {#if} block does not have a parent

{#if condition}
  <div />
{/if}

Svelte REPL

You'll see that

Svelte creates an extra anchor element
The anchor element is inserted after the {#if} block.
Subsequently in the u_p_date function, Svelte insert {#if} block before the anchor element.

if_block.m(if_block_anchor.parentNode, if_block_anchor);

When the {#if} condition changes, {#if} block will replace and insert new elements before the anchor element.

But why?

This is because a Svelte component can be used in anywhere.

Let's take a look at the scenario below:

<!-- A.svelte -->
{#if condition}
  <div id="a" />
{/if}

<!-- B.svelte -->
<div id="b" />

<!-- App.svelte -->
<script>
  import A from './A.svelte';
  import B from './B.svelte';
</script>

<div id="parent">
  <A />
  <B />
</div>

In the A.svelte, the {#if} block is the last child, it does not have any sibling elements after it.

Let's first assume we don't have the anchor element. When the condition changes from false to true, Svelte will have to insert the new element <div id="a"> into its parent. And because there's no next element after {#if} block, and no anchor element, we will have to insert before null. In which, the <div id="a" /> will be inserted as the last child of the parent element, <div id="parent">. And hey, we got ourselves a bug! Elements inside <A /> appears after <B />!

<div id="parent">
  <div id="b"></div>
  <div id="a"></div> <!-- newly inserted element -->
</div>

We can prevent this from happening by adding an anchor element.

When the condition is false, our DOM looks like this:

<div id="parent">
  <#text /> <!-- an empty text node, not visible to the user -->
  <div id="b"></div>
</div>

And when the condition turns true, we insert <div id="a" /> before the anchor element:

<div id="parent">
  <div id="a"></div> <!-- newly inserted element -->
  <#text /> <!-- an empty text node, not visible to the user -->
  <div id="b"></div>
</div>

Yay, we maintain the order of <A /> and <B /> 🎉 !

The anchor element to the {#if} block, is like an anchor to a ship, "Here is where {#if} block should insertBefore() !"

4. {#if} block followed by another logic block

The final scenario. {#if} block followed by another logic block:

{#if condition}
  <div id="a" />
{/if}
{#if condition2}
  <div id="b" />
{/if}

The 2nd {#if} block condition could be true or false. Which means <div id="b" /> could be there or not there.

So, to know where we should insert <div id="a" /> when chaging the condition, we need an anchor element after the 1st {#if} block, before the 2nd {#if} block.

Closing Note

We've covered how Svelte compiles an {#if} block, as well as how and why an anchor element is needed for the {#if} block.

If you wish to learn more about Svelte, follow me on Twitter.

I'll post it on Twitter when the next part is ready, the next post will be about {#each} logic block.

Contributing to Svelte - Fixing issue #5012

Tan Li Hau — Thu, 25 Jun 2020 08:00:00 +0000

Background

Following Contributing to Svelte - Fixing issue #4392, I find it interesting to write my thought process down on fixing a Svelte issue.

So today, I’m going to walk through a new issue, #5012.

The bug

Slot containing only {@html value} renders in wrong place on update #5012

When a slotted component is instantiated and the only contents of the slot is {@html value}, changing value will cause the HTML-ized value to render at the end of the slot’s parent element (i.e. after all sibling elements) instead of in the correct place.

To Reproduce

https://svelte.dev/repl/1f9da40bca4b44a089041e826648de2f

Click the Switch button and see that the contents of the slot moves to the end.

Expected behavior

Slot continues to render in the correct place.

Information about your Svelte project:

Looks like this appeared in version 3.7 and is still present in 3.23.2. If I run the REPL on 3.6.11 it behaves properly.

Severity

Potentially serious, but not serious for me.

Can be worked around by changing the slot contents to <div>{@html value}</div> or changing the child component to use <div><slot /><div>, which works fine for me.

Verifying the bug

I clicked into the REPL and tried to understand about the bug.

Initially, you see 2 lines of text, “Another first line”, “This line should be last.”.

But as soon as I updated the {@html content}, the {@html content} moved to be after the “This line should be last.” and stayed there.

Yup. This is indeed a bug! 🐛

Investigating the bug

It’s amazing that the issue author tracked down the regression behavior of this issue, stating that it started happening since 3.7. Probably because the author just upgraded Svelte from < 3.7, or maybe he tried every versions to figure out whether it is regression bug or an undiscovered bug. Anyway, kudos to the issue author! 💪 💪

Most open source projects maintain a change log file, usually named CHANGELOG.md located at the root of the project folder, so that you can figured out what’s added / removed / updated in each version.

You can find Svelte’s CHANGELOG.md here.

From the changelog, the most relevant commits seemed to be “Remount HTML tags correctly (#3329)”

Reading through the PR, it seemed that #3329 was when HtmlTag is first introduced!

HtmlTag

HtmlTag is a helper class that helps Svelte manage raw {@html ...} tag.

// in the compiled Svelte code,
// you would see the use of `HtmlTag`
// when you use `{@html ...}`
const html_tag = new HtmlTag(anchor);
// mounting raw html string, call the `m`ount method
html_tag.m('<div>content</div>', target, anchor);
// when the html string content change, call the u`p`date method
html_tag.p('<b>new</b>html<br />');
// when unmount, call the `d`etach method
html_tag.d();

The HtmlTag instance provides the m, p, d method, and it will maintain the HTML elements created through the HTML string.

So, before v3.7, {@html ...} was handled differently, and from the PR, I assume it was more buggy than the current implementation, albeit getting the case reported by this issue #5012 right. So, there’s no reverting back, nor taking the implementation pre-v3.7 as a reference to figure this bug out.

Reading through the implementation of the HtmlTag, it seemed that the anchor is a key to this issue.

HtmlTag uses insertBefore to insert HTML elements into the DOM. There’s a nullable 2nd argument for insertBefore, if it is null, the element will be inserted at the end of the parent.

In this case, the anchor is indeed null, so when there’s a change in the HTML content, the previous HTML elements were removed and the new HTML elements were inserted at the end of the parent.

<!-- Initially -->
<article>
  <!-- slot -->
  {@html content}
  <!-- slot -->
  <p>
    This line should be last.
  </p>
</article>

<!-- when the html content changed -->
<article>
  <!-- slot -->
  <!-- {@html content} removed -->
  <!-- slot -->
  <p>
    This line should be last.
  </p>
  {@html content}
  <!-- inserted at the end of the parent -->
</article>

Why doesn’t the {@html content} added at the end of the parent in the initial render? Well, the elements are added in order during mounting. The HTML elements from HtmlTag was added at the end of the parent, followed by the <p>This line should be last</p>.

The anchor is an argument to the HtmlTag constructor, so one can safely assume that it is not always null.

So, I tried out using {@html content} in various ways, to figure out what may be an anchor for the HtmlTag

Repro #1 (REPL)

<script>
  let content = 'first line';
</script>

{@html content}<button on:click={() => {content = 'line first';}} />

// compiled js
// ...
  c() {
    button = element("button");
    html_tag = new HtmlTag(button);
  },
// ...

In this case, the <button /> element turns out to be the anchor, which totally make sense, as the html content should be inserted before <button />.

So, it seemed like the anchor is the next element right after {@html ...}. 🤔

Repro #2 (REPL)

<script>
  import Foo from './Foo.svelte';
  let content = 'first line';
</script>

<button on:click={() => {content = 'line first';}} />
{@html content}<Foo />

// compiled js
// ...
  c() {
    button = element("button");
    t = space();
    html_anchor = empty();
    create_component(foo.$$.fragment);
    html_tag = new HtmlTag(html_anchor);
  },
// ...

If the next element right after {@html ...} is a component, then Svelte will insert a empty Text node in between {@html ...} and the component, and the anchor is the empty Text node.

Well, that make sense too, because we can’t see what’s inside the component, we can’t get the first element rendered in the component as the anchor. So, an extra empty Text node is used for anchoring.

So, it seemed like the anchor for the HtmlTag depends on the next element, and the HtmlTag itself is the last element, then the anchor would be null.

This seemed fine in most cases, as in if the HtmlTag is indeed the last element of its parent, then, we don’t need an anchor. Adding and updating HtmlTag will always add HTML elements at the end of its parent.

However, I figured there are 2 edge cases that this assumption may not be true.

The 1st edge case is the one reported in the issue #5012, if the {@html ...} is the last element within a slot. As we can’t tell how the slot would be used in the component, it may not be the last element of it’s parent.

<div>
  <slot />
  <div>This is the last child</div>
</div>

The 2nd edge case is that {@html ...} is the last element, but it is a the root of the Component.

<!-- Component.svelte -->
<script>
  export let content;
</script>

{@html content}

<!-- App.svelte -->
<script>
  import Component from './Component.svelte';
</script>
<div>
  <Component content={'<div>html string</div>'}/>
  <div>This is the last child</div>
</div>

REPL

As you can see in this contrived example, we can’t assume where the component is being used by its parent, so, even it seemed to be the last element in the component, it may not be the case in the parent component.

Fixing the bug

Once we figured out the cause of the bug, the fix is much simpler.

Just as how Svelte will add a empty Text node as an anchor if the next element is a component, we are going to add the same anchor if

- the `{@html ...}` has no next element, and

either

{@html ...} is at the root of a slot, or
{@html ...} is at the root of a component.

I know my way in the Svelte repo, good enough to know where to add this extra condition.

But if you are new, you can try global search the keyword html_anchor, the variable name of the anchor added by Svelte, it should lead you to it.

// src/compiler/compile/render_dom/wrappers/RawMustacheTag.ts#L42

const needs_anchor = in_head || (this.next && !this.next.is_dom_node());

// ...
if (needs_anchor) {
  block.add_element(html_anchor, x`@empty()`, x`@empty()`, parent_node);
}

Link to Github

Here we see that the condition of adding an anchor is that if

it is in the <svelte:head>, or
the next element is not a dom element, (which could be a component, or logic blocks (oh why didn’t I think about this case too?))

const needs_anchor =
  in_head ||
  (this.next
    ? !this.next.is_dom_node()
    : !this.parent || !this.parent.is_dom_node());

So, we check if

it has a parent (if it is at the root of component), or
if the parent is not an element (it could be within a slot, or a logic block {#if})

For the test case, I used to 2 edge case examples, try to simulate some clicks, and make sure that the {@html ...} stay in place even after the HTML content changes.

export default {
  html: `
    <button>Switch</button>
    <p>Another first line</p>
    <p>This line should be last.</p>
  `,
  async test({ assert, target, window }) {
    const btn = target.querySelector('button');
    const clickEvent = new window.MouseEvent('click');

    // simulate clicks
    await btn.dispatchEvent(clickEvent);

    assert.htmlEqual(
      target.innerHTML,
      `
        <button>Switch</button>
        <p>First line</p>
        <p>This line should be last.</p>
      `
    );

    // simulate clicks
    await btn.dispatchEvent(clickEvent);

    assert.htmlEqual(
      target.innerHTML,
      `
        <button>Switch</button>
        <p>Another first line</p>
        <p>This line should be last.</p>
      `
    );
  },
};

You can read the Pull Request #5061 to see all the test cases written up.

If you wish to learn more about Svelte, follow me on Twitter.

If you have anything unclear about this article, find me on Twitter too!

Contributing to Svelte - Fixing issue #4392

Tan Li Hau — Sat, 23 May 2020 08:00:00 +0000

Background

As Svelte gains more attention, I find that more and more people are interested in contributing to Svelte.

Of course, contributing to Svelte, does not mean to contribute only in code, it could be:

answering questions about Svelte, on social media, Stack Overflow, or Discord
improving Svelte docs, or write tutorials and articles about Svelte
organising and speaking in meetups about Svelte

For those who want to contribute in code, most people are unsure where to start. So I wrote The Svelte Compiler Handbook as an overview of the Svelte source code.

However, today, I want to try a different tone.

I am going to tell you an anecdote on how I investigated and fixed a bug in Svelte.

I documented down my train of thoughts as detailed as possible.

I hope this gives anyone who is reading, a glimpse on how to work on the Svelte source code.

The story begins

I was combing through bugs on GitHub, and found this rather interesting bug:

Select multiple value does not get set with spread props #4392

Adding any type of spread, even an empty object {...{}}, causes the value not to be set:

<script>
  let value = ['Hello', 'World'];
</script>

<select multiple {value} {...{}}>
  <option>Hello</option>
  <option>World</option>
</select>

To reproduce: REPL.

Verifying the bug

I clicked into the REPL and tried to understand about the bug.

I found that if the <select multiple> has spread attribute {...any}, the value attribute will not be reactive. Changes in the value of value will not be reflected to the <select>.

I noticed the REPL link uses the version 3.18.1, it’s not the latest version of Svelte. At the point of writing, Svelte is at 3.22.3. I tried removing the ?version=3.18.1 from the query params to verify whether the bug has fixed, and realised that the bug is still there. (Great! Something interesting to investigate into.)

To understand the current status of the issue, I read through the comments. According to Conduitry, the issue is related to Radio/checkbox input with bind:group and spread props makes variable undefined #3680 and can be fixed together. However, the issue #3680 was fixed and closed, yet this issue is still open.

Nevertheless, I read through the PR for the closed issue #3680, roughly understand how it was fixed and hopefully it can give me some inspirations on this issue.

Investigating the bug

Once I verified that the behavior described in the issue is unexpected and reproducible in the latest version of Svelte, I copied the REPL code into my local machine to investigate.

I have a test-svelte folder ready in my local machine, where I created using Svelte Template. I have npm linked my local Svelte clone to the test-svelte folder, so I can rebuild test-svelte anytime with the latest changes done to my Svelte clone.

- /Projects
  - svelte <-- cloned from https://github.com/sveltejs/svelte
  - test-svelte <-- initialised with Svelte Template
    - node_modules/svelte <-- symlink to `/Projects/svelte`

I have yarn dev running in the Svelte folder, so any changes I make gets compiled immediately.

I prefer to build test-svelte and serve it with http-server rather than start a dev server test-svelte in watch mode. That allows me to

Run the http-server in the background while tweaking the Svelte code or the test-svelte app.
Not having to restart the dev server whenever I’ve made changes to the Svelte code
Able to inspect and modify bundle.js without worrying that accidentaly save in the test-svelte app will overwrite the bundle.js

Looking at the different bundle.js generated from with {...spread} attributes and without spread attributes

<script>
  let value = ['Hello', 'World'];
</script>

<!-- with spread -->
<select multiple {value} {...{}}>
  <option>Hello</option>
  <option>World</option>
</select>

<!-- without spread -->
<select multiple {value}>
  <option>Hello</option>
  <option>World</option>
</select>

I found the following diffs in the bundled output:

+ let select_levels = [{ multiple: true }, { value: /*value*/ ctx[0] }, {}];
+   let select_data = {};
+   for (let i = 0; i < select_levels.length; i += 1) {
+ select_data = assign(select_data, select_levels[i]);
+   }
- let select_value_value;

  return {
    c() {
      /* ... */
      set_attributes(select, select_data);
    },
    m(target, anchor) {
      /* ... */
- select_value_value = /*value*/ ctx[0];

- for (var i = 0; i < select.options.length; i += 1) {
- var option = select.options[i];
- option.selected = ~select_value_value.indexOf(option.__value);
- }
    },
- p: noop,
+ p(ctx, [dirty]) {
+ set_attributes(select, get_spread_update(select_levels, [{ multiple: true }, dirty & /*value*/ 1 && { value: /*value*/ ctx[0] }, {}]));
+ },
    /* ... */
  };

Well, I know I haven’t cover how spread attribute works in any of my “Compile Svelte in your Head” articles, but the general idea is that, Svelte builds an array of attributes, and then apply it to the element / Component.

For example, if we write the following in Svelte

<div foo="foo" {...bar} baz="baz" {...qux} />

It gets compiled to something like this:

const levels = [{ foo: 'foo' }, bar, { baz: 'baz' }, qux];
// build the attribute maps
const data = {};
for (let i = 0; i < levels.length; i++) {
  data = Object.assign(data, levels[i]);
}

// set attribute to element
for (const attributeName in data) {
  div.setAttribute(attributeName, data[attributeName]);
}

// if `bar` changed
const updates = get_spread_update(levels, [false, bar, false, false]);
// updates will return the updates needed to make, in this case, the diff in `bar`, eg: { aa: '1' }
for (const attributeName in updates) {
  div.setAttribute(attributeName, updates[attributeName]);
}

So, this roughly explains the additional code added into the bundle.js for handling spread attributes.

However the code that is removed, is something I am not familiar with.

// in `mount` method
for (var i = 0; i < select.options.length; i += 1) {
  var option = select.options[i];
  option.selected = ~select_value_value.indexOf(option.__value);
}

It seems like we are trying to set option.selected after we mount the <select> element. Not sure how important is that to us.

To verify that the bug is because that the above code snippet is missing when having a spread attribute, I tried adding the code snippet into the bundle.js manually, and refresh the page.

// ...
  m(target, anchor) {
    insert(target, select, anchor);
    append(select, option0);
    append(select, option1);
    for (var i = 0; i < select.options.length; i += 1) {
      var option = select.options[i];
      option.selected = ~ctx[0].indexOf(option.__value);
    }
  },
// ...

Instead of ~select_value_value.indexOf(...), I changed it to ~ctx[0].indexOf(...), as select_value_value wasn’t created when using spread attribute.

…and it works!

So, now we know that the bug is caused by missing setting option.selected on mount, now its time to figure out what the code snippet is not generated when there’s a spread attribute.

To quickly find out why something is not generated, I tried to look for where it is generated, figuring out probably whether certain condition was not set correctly to cause the Svelte compiler to omit out the code snippet.

To find the right place to start looking is an art. Usually I try to global search a small snippet of code that is most likely static , something that has no variable name, for example:

.indexOf(option.__value)
.options.length;
.selected = ~

The only search result I got when searching for .indexOf(option.__value) is in src/runtime/internal/dom.ts

export function select_options(select, value) {
  for (let i = 0; i < select.options.length; i += 1) {
    const option = select.options[i];
    option.selected = ~value.indexOf(option.__value);
  }
}

Anything within src/runtime/ are helper functions that are referenced from the output code, to reduce the output code size. Hmm… probably we should reuse the select_options helper function:

// ...
  m(target, anchor) {
    insert(target, select, anchor);
    append(select, option0);
    append(select, option1);
-   for (var i = 0; i < select.options.length; i += 1) {
-     var option = select.options[i];
-     option.selected = ~ctx[0].indexOf(option.__value);
-   }
+   select_options(select, select_value_value);
  },
// ...

Anyway, src/runtime/internal/dom.ts is not where I am looking for, so I tried searching .options.length

src/compiler/compile/render_dom/wrappers/Element/Attribute.ts

updater = b`
  for (var ${i} = 0; ${i} < ${element.var}.options.length; ${i} += 1) {
    var ${option} = ${element.var}.options[${i}];

    ${if_statement}
  }
`;
block.chunks.mount.push(b`
  ${last} = ${value};
  ${updater}
`);

Yes, this is most likely where it is.

Firstly, let me update the updater to use the src/runtime/ select_options helper instead:

if (is_multiple_select) { updater = b`@select_options(${element.var}, ${last});`;} else { updater = b`@select_option(${element.var}, ${last});`;}
block.chunks.mount.push(b`
  ${last} = ${value};
  ${updater}
`);

The b`...`, is called a tagged template, where the b is a function that takes in the template literal and return something. In this case, the b function returns an Abstract Syntaxt Tree (AST).

The b function comes from code-red, a utility to generate a JavaScript AST node. Beside b, code-red provides a few helper functions:

b returns a block node
x returns an expression node
p returns a object property node

These helper functions are useful in generating code in Svelte compiler, particularly because the placeholder itself can takes in another AST node:

const node = { type: 'Identifier', name: 'foo' };
const code = b`const ${node} = 1;`; // returns an AST node for `const foo = 1;`

@ in front of @select_option is a convention in Svelte, where it will get replaced to refer to helpr functions in src/runtime/ before writing the generated AST out:

const code = b`@foo(bar)`;
// turns into

import { foo } from 'svelte/internal';
foo(bar);

Coming back to figure out why this piece of code is not executed when there’s a spread attribute,

if (is_legacy_input_type) { // ...
} else if (is_select_value_attribute) { if (is_multiple_select) {
    updater = b`@select_options(${element.var}, ${last});`;
  } else {
    updater = b`@select_option(${element.var}, ${last});`;
  }

  block.chunks.mount.push(b`
    ${last} = ${value};
    ${updater}
  `);
} else if (is_src) {
  // ...
}

I tried adding console.log before the if statement, to figure out the value for is_legacy_input_type and is_select_value_attribute:

console.log( 'is_legacy_input_type:', is_legacy_input_type, 'is_select_value_attribute:', is_select_value_attribute);if (is_legacy_input_type) {
  // ...
}

To my surpise, there was no log. AttributeWrapper#render wasn’t executed.

I tried removing the spread attribute, and verified from the log that the AttributeWrapper#render method was indeed executed when there’s no spread attribute.

To figure out the caller of the AttributeWrapper#render method, I added console.trace at the top of the method:

render(block: Block) {
  console.trace('trace'); // ...
}

Trace: trace
  at AttributeWrapper.render (/Projects/svelte/compiler.js:8269:11) at /Projects/svelte/compiler.js:10749:14
  at Array.forEach (<anonymous>)
  at ElementWrapper.add_attributes (/Projects/svelte/compiler.js:10748:19) at ElementWrapper.render (/Projects/svelte/compiler.js:10472:8)
  at /Projects/svelte/compiler.js:10454:11
  at Array.forEach (<anonymous>)
  at ElementWrapper.render (/Projects/svelte/compiler.js:10453:24)
  at FragmentWrapper.render (/Projects/svelte/compiler.js:13030:18)
  at new Renderer (/Projects/svelte/compiler.js:13112:17)

This brought me to src/compiler/compile/render_dom/wrappers/Element/index.ts

add_attributes(block: Block) {
  // Get all the class dependencies first
  this.attributes.forEach((attribute) => {
    if (attribute.node.name === 'class') {
      const dependencies = attribute.node.get_dependencies();
      this.class_dependencies.push(...dependencies);
    }
  });

  if (this.node.attributes.some(attr => attr.is_spread)) {
    this.add_spread_attributes(block);
    return;
  }

  this.attributes.forEach((attribute) => {
    attribute.render(block); });
}

If there’s a spread attribute, it will call the this.node.attributes.some(attr => attr.is_spread) method instead of calling attribute.render(block), so that’s probably why AttributeWrapper#render wasn’t called.

I looked into the method add_spread_attributes, found out it contain only the code about handling spread attributes as I explained earlier. It didn’t have any code related to select_options, so I figured that, maybe <select multiple> with spread attribute is an edge case that wasn’t handled currently at all.

So, I tried to add a special check for this case at the bottom of the add_spread_attributes method:

add_spread_attributes(block: Block) {
  // ...
  // for `<select>` element only
  if (this.node.name === 'select') {
    block.chunks.mount.push(
      b`@select_options(${this.var}, ${data}.value);`
    );
  }
}

As mentioned in the The Svelte Compiler Handbook, a block is where it keeps the code to generate the create_fragment function. The return object of the create_fragment function contains various method as mentioned in Compile Svelte in your Head, such as c(), m() and d(). To add code into different method, you can push them into the array in block.chunks, for example:

// push `const foo = 1` to `m()`
block.chunks.mount.push(b`const foo = 1`);

// push `const bar = 2` to `c()`
block.chunks.create.push(b`const bar = 2`);

I tried adding @select_options(...) into the m() method and yup, the <select> element is pre-selected correctly!

Fixing the bug

To ensure the bug is fixed, I need to come up with a test.

Usually I come up with test cases that try to entail various scenario I can imagine.

In this example, we’ve manually tested the case where the <select multiple {value} {...{}}>, the value is set correctly during initialisation. but have we check the case where:

we update the value of value, will the <select> get updated accordingly?
if the value is overriden by the spreaded attribute, eg <select mutliple {value} { ...{value: []} }>?

Ideally, the test cases come up should be failed before the fix, and passed after the fix.

So here’s the test case I came up:

<script>
  let value = ['Hello', 'World'];
  export let spread = {};
</script>

<select multiple {value} {...spread}>
  <option>Hello</option>
  <option>World</option>
</select>

<input type="checkbox" value="Hello" bind:group={value}>
<input type="checkbox" value="World" bind:group={value}>

I can check and uncheck the checkbox to change the value of value to verify the the value is reactive, and <select> will get updated accordingly.

Besides that, I exported spread, so that I can change the object to something object to contain value, eg: { value: [] }, and see how <select> will update accordingly. Make sure that our fix not just work with value attribute, and also when the value is spreaded into <select>.

You may think that we are familiar with our fix, we know what it will fix, what it will not fix, do we need think up and write all the edge cases?

Well, I think you should. Future you will thank the present you when he encounter a fail test, that just mean his change may have an unintentional regression change. If you don’t have the test case, the future you will never know what edge case he didn’t accounted for.

Runtime test cases are added into test/runtime/samples/. Each folder represent 1 test case. Inside the folder, the component to be tested is named App.svelte, and the test case is written _config.js.

_config.js default exports a object:

_config.js

export default {
  // initial props to passed to the component
  props: { /*...*/ },
  // initial rendered html
  html: ``,
  // test case
  async test({ assert, target }) {
    // you can test the behavior of the component here
  },
};

An example of test case of unchecking the checkbox, and verify <select> value get updated

export default {
    // ...
    async test({ assert, target, window }) {
    // find the element
        const [input1, input2] = target.querySelectorAll("input");
        const select = target.querySelector("select");
        const [option1, option2] = select.childNodes;

    // uncheck the checkbox
        const event = new window.Event("change");
        input1.checked = false;
        await input1.dispatchEvent(event);

    // verify the component updated correctly
        const selections = Array.from(select.selectedOptions);
        assert.equal(selections.length, 1);
        assert.ok(!selections.includes(option1));
        assert.ok(selections.includes(option2));
    },
};

To run only this test, so that we can focus on ensuring the test case pass, we can set solo: true:

export default { solo: true };

Quick tip: running npm run test will build Svelte code first before executing the test. If you are like me, running npm run dev on the background, Svelte code is build on every code change. So, npm run quicktest would allow you to skip the pretest build, and run the test suite immediately.

With the test, I realised that I didn’t handle the case when the value is updated.

So I guess what I needed to do is to add the same code in the p() (update) method too!

add_spread_attributes(block: Block) {
  // ...
  if (this.node.name === 'select') {
    block.chunks.mount.push(
      b`@select_options(${this.var}, ${data}.value);`
    );
    block.chunks.update.push(
      b`@select_options(${this.var}, ${data}.value);`
    );
  }
}

Well, of course in this way, the select_options get executed unconditionally whenever any variable is updated.

I need to make sure that the select_options(...) inside the p() method get executed only when the value of value changes, and also probably when spread changes too, because it could potentially override the value of value.

If you’ve read Compile Svelte in your Head - Bitmask in Svelte, you know that Svelte uses bitmask to check any variable changes.

How do I know what is the bitmask to use in this case, well I dont have to.

I can use renderer.dirty(dependencies) to help me with that:

add_spread_attributes(block: Block) {
  // ...
  if (this.node.name === 'select') {
    const dependencies = [...];
    block.chunks.mount.push(
      b`@select_options(${this.var}, ${data}.value);`
    );
    block.chunks.update.push(
      // block.renderer.dirty(...) will give me `dirty & bitmask`
      b`if (${block.renderer.dirty(dependencies)}) @select_options(${this.var}, ${data}.value);`
    );
  }
}

Next, I need to figure out what are the dependencies to be included. In this particular case, the dependencies of all attributes have to be taken consideration, because it is hard to tell which one would be eventually applied due to the spread attribute.

add_spread_attributes(block: Block) {
  // ...
  if (this.node.name === 'select') {
    const dependencies = new Set(); for (const attr of this.attributes) { for (const dep of attr.node.dependencies) { dependencies.add(dep); } } block.chunks.mount.push(
      b`@select_options(${this.var}, ${data}.value);`
    );
    block.chunks.update.push(
      b`if (${block.renderer.dirty(dependencies)}) @select_options(${this.var}, ${data}.value);`
    );
  }
}

After a few tweaks, finally I passed all my test cases, and its time to create a pull request!

Submitting the fix

Before pushing the fix to remote, it is important to make sure that all the lints and typescript definitions are correct. You can run npm run lint --fixed for linting, and npm run tsd to generate typescript definition.

If you are unsure on how to create a pull request, you can check out How to make your first pull request on GitHub.

I pushed my branch and created a Pull Request to Svelte, and now I am waiting for feedback and for it to get merged.

Svelte is not maintained by full-time maintainers, everyone has their full-time job, so please be patient and be nice.

If you wish to learn more about Svelte, follow me on Twitter.

If you have anything unclear about this article, find me on Twitter too!

Compile Svelte in your head (on:, bind: and use:)

Tan Li Hau — Thu, 07 May 2020 08:00:00 +0000

Previously, I detailed how $$invalidate works, described how bitmask was used in $$invalidate, and explained how reactive declarations work as well.

In this article, we are going to look into 3 DOM related directives:

on: for event handlers
bind: for bindings
use: for actions

To make sure we are on the same page, let’s first explain how these 3 directives work.

The `on:`, `bind:` and `use:`

`on:` event handlers

You can use the on: directive to listen to any event on an element:

<script>
  function handleMouseMove(event) {}

  function handleClick(event) {}
</script>

<!-- You can pass in as variable -->
<div on:mousemove={handleMouseMove} />

<!-- or you can inline the event handler -->
<div on:mousemove={event => { /*...*/ }} />

<!-- You can modify event handler with modifiers -->
<div on:click|stopPropagation|once={handleClick}>

`bind:` bindings

The bind: directive allows you to bind a variable to a property of an element.

Updating the variable will modifying the property of the element, conversely, modifying the property of the element via interacting with the element will, in turn, update the variable.

<script>
  let name, yes;
</script>

<!-- You can bind `name` to input.value -->
<!-- Changing `name` will update input.value to be the value of `name` and -->
<!-- changing input.value will update `name` to be input.value -->
<input bind:value={name} />

<!-- You can bind input.checked for a checkbox input -->
<input type="checkbox" bind:checked={yes} />

`use:` actions

The use: directive is called “Action”. It provides you an interface to enhance your element.

You pass a function to the use: directive of an element and the function will be called when your element is mounted.

The function should return an object in which the destroy method of the object will be called when the element is unmounted.

<script>
  function doSomething(element) {
    // do something with the element
    return {
      destroy() {
        // cleanup
      }
    }
  }
</script>

<div use:doSomething />

This is useful when you want to interface with 3rd-party libraries:

<script>
  import Draggable from 'the-draggable-library';

  function doSomething(element) {
    const draggable = new Draggable(element); draggable.start(); return {
      destroy() {
        draggable.stop(); }
    }
  }
</script>

<div use:doSomething />

You can pass in parameters to the use: directive, to bring in reactivity into your actions

<script>
  import Draggable from 'the-draggable-library';

  let options = { foo: true, bar: true };

  function doSomething(element, options) { const draggable = new Draggable(element, options); draggable.start();

    return {
      update(options) { draggable.update(options); }, destroy() {
        draggable.stop();
      }
    }
  }
</script>

<div use:doSomething={options} />

<label>
  <input type="checkbox" bind:checked={options.foo} />
  Foo
</label>
<label>
  <input type="checkbox" bind:checked={options.bar} />
  Bar
</label>

You can visit Svelte’s interactive tutorial to learn more about:

The Vanilla JS

Now, let’s refresh ourselves with how we can implement an event handler, bindings, and actions without using any framework.

Event handler

As mentioned in the Part 1 of the series, we can use element.addEventListener to listen to events.

element.addEventListener('click', handleClick);

The event listener takes in an optional 3rd argument, which allows you to specifies the characteristics of the event handler:

element.addEventListener('click', handleClick, {
  capture: true, // triggered before any child element
  once: true, // triggered at most once
  passive: true, // indicates that will never call `preventDefault` to improve performance
});

event.preventDefault

event.preventDefault allows you to prevent the default behavior of the event, for example submitting form for <button type="submit" /> or navigating to the target for <a href="...">.

element.addEventListener('click', event => {
  event.preventDefault();
});

event.stopPropagation

event.stopPropagation allows you to prevent event to continue propagate.

<div on:click={event => {
  console.log('click not triggered');
}}>
  <div on:click={event => {
    event.stopPropagation(); console.log('click');
  }}>
  </div>
</div>

To remove the event listener, you need to call element.removeEventListener with the same event type, listener and capture/useCapture flag. You can check out the MDN docs on “Matching event listeners for removal”.

element.removeEventListener('click', handleClick);

Bindings

Binding is to synchronise between the value of a variable and a property of an element.

To synchronise the variable to a property of an element, we need to observe the value of the variable. When it changes, apply it to the property of the element.

You can check out my previous article “Reactivity in Web Frameworks” on how we get notified when the value of a variable changed.

On the other hand, to synchronise the property of an element to a variable, we listen to an event of the element , depending on the property, and update the value of the variable when it happens.

// binding variable `checked` with the checkbox `checked` property
let checked;
let input = document.querySelector('#checkbox');

// synchronise variable `checked` to checkbox `checked` property
observe(checked, newValue => {
  input.checked = newValue;
});

// synchronise checkbox `checked` property to variable `checked`
// listen to `change` event for `checked` property
input.addEventListener('change', event => {
  checked = input.checked;
});

Some observations:

- The name of the event and the property name of the element may not be the same.

In this example, we listen to "change" event for the checkbox checked property.

- It is almost impossible to bind a property of an element, if there’s no event fired from the element to indicate the property has changed

A recent example I found out is the HTMLDialogElement. It has "close" but not "open" event, which makes it hard to implement bind:open on the dialog element.

Maybe an alternative would be using MutationObserver, which I haven’t seen any usage of it in Svelte codebase yet.

Actions

Action is a function that gets called when your element is created and mounted onto the DOM.

The function returns an object, with 2 methods:

update, which gets called when the parameters change
destroy, which gets called when the element is removed from the DOM

function actionFn(element, parameter) {
  return {
    update(newParameter) {},
    destroy() {},
  };
}

// When element is mounted onto the DOM
let parameter = 1;
const actionObj = actionFn(element, parameter);

// When parameter changes
parameter = 2;
actionObj.update(parameter);

// When element is removed from the DOM
actionObj.destroy();

The Compiled JS

Now let’s take look at how Svelte compiles on:, bind: and use: directives into output JavaScript.

`on:` directive

<script>
  function onChange() {}
</script>

<input on:change={onChange} />

Svelte REPL

The output code:

/* App.svelte generated by Svelte v3.22.2 */
// ...
function create_fragment(ctx) {
  let input;
  let dispose;

  return {
    c() {
      input = element('input');
    },
    m(target, anchor, remount) {
      insert(target, input, anchor);
      if (remount) dispose(); dispose = listen(input, 'change', /*onChange*/ ctx[0]); },
    d(detaching) {
      if (detaching) detach(input);
      dispose(); },
  };
}

function instance($$self) {
  let i = 0;
  function onChange() {
    i++;
  }
  return [onChange];}

// ...

Some observations:

Svelte adds event handler, listen(...), in the _m_ount method.
Svelte removes event handler, dispose(), in the _d_estroy method.

As pointed out in Part 1 #listen and dispose, to optimise for minification, the dispose variable could be a function or an array of functions, depending on having one or many event handlers.

We will discuss remount in the future, as it is related to remounting elements while reordering items within each block.

Event modifiers

Event handlers can have modifiers that alter their behavior.

<script>
    let i=0;
    function onClick() {
        i++;
    }
</script>

<button on:click|preventDefault={onClick} />
<button on:change|stopPropagation={onClick} />
<button on:change|once={onClick} />
<button on:change|capture={onClick} />

<!-- Chain multiple modifiers -->
<button on:click|preventDefault|stopPropagation|once|capture={onClick} />

Svelte REPL

The output code:

/* App.svelte generated by Svelte v3.22.2 */
// ...
function create_fragment(ctx) {
  // ...
  return {
    c() { /* ... */ },
    m(target, anchor, remount) {
      // ...
      dispose = [listen(button0, "click", prevent_default(/*onClick*/ ctx[0])), listen(button1, "change", stop_propagation(/*onClick*/ ctx[0])), listen(button2, "change", /*onClick*/ ctx[0], { once: true }), listen(button3, "change", /*onClick*/ ctx[0], true), listen( button4, "click", stop_propagation(prevent_default(/*onClick*/ ctx[0])), { once: true, capture: true } ), ]; },
    // ...
  };
}

Some observations:

Svelte handles different modifiers differently.
For capture, once, and passive modifiers, which they are part of the options for element.addEventListener, they will be passed as options into the listen function.
For stopPropagation, preventDefault, and self modifiers, the event handler is decorated with respective decorator functions.

An example implementation of the prevent_default decorator function:

function prevent_default(fn) {
  return function(event) {
    event.preventDefault();
    return fn.call(this, event);
  };
}

`bind:` directive

<script>
    let checked = false;
    function updateChecked() {
        checked = true;
    }
</script>

<input type="checkbox" bind:checked />

Svelte REPL

The output code:

/* App.svelte generated by Svelte v3.22.2 */
// ...
function create_fragment(ctx) {
  let input;
  let dispose;

  return {
    c() { /* ... */ },
    m(target, anchor, remount) {
      insert(target, input, anchor);
      input.checked = /*checked*/ ctx[0];
      if (remount) dispose(); dispose = listen(input, 'change', /*input_change_handler*/ ctx[1]); },
    p(ctx, [dirty]) {
      if (dirty & /*checked*/ 1) { input.checked = /*checked*/ ctx[0]; } },
    d(detaching) {
      if (detaching) detach(input);
      dispose(); },
  };
}

function instance($$self, $$props, $$invalidate) {
  let checked = false;

  function updateChecked() {
    $$invalidate(0, (checked = true)); }

  function input_change_handler() { checked = this.checked; $$invalidate(0, checked); }
  return [checked, input_change_handler];
}

Some observations:

To synchronise the value of the variable to the property of the element:

Svelte wraps the update of the variable checked with $$invalidate(...)

- In the u_p_date method, if the variable `checked` is updated, Svelte sets `input.checked` to the value of the variable `checked`.

To syncrhonise the property of the element to the variable

Svelte creates an input handler that reads the this.checked property of the input and calls $$invalidate(...) to update it.
Svelte sets up listen(...) in the _m_ount method and dispose(...) in the _d_estroy method for the input handler

`use:` directive

<script>
    let i = '';
    function action() {}
  function updateI() {
    i++;
  }
</script>

<div use:action={i} />

Svelte REPL

The output code:

/* App.svelte generated by Svelte v3.22.2 */
// ...
function create_fragment(ctx) {
  // ...
  let action_action;

  return {
    c() { /* ... */ },
    m(target, anchor, remount) {
      insert(target, div, anchor);
      if (remount) dispose(); dispose = action_destroyer( (action_action = action.call(null, div, /*i*/ ctx[0])) ); },
    p(ctx, [dirty]) {
      if (action_action && is_function(action_action.update) && dirty & /*i*/ 1) action_action.update.call(null, /*i*/ ctx[0]); },
    d(detaching) {
      if (detaching) detach(div);
      dispose(); },
  };
}

Some observations:

Creating action_action object by calling the action function in the _m_out method
When the paramter change, call the action_action.update method with the updated parameter in the u_p_date method
action_destroyer returns the dispose function. The dispose function makes sure that action_action.destroy is a function before calling it.

The order of directives

As both the bind: and the on: directives add event listeners to the element, the order of adding event listener may have nuance side effects.

Imagine the following scenario:

<script>
  let before = ''
  let after = '';
  function uppercase(event) {
    // modifying the input.value
    event.target.value = event.target.value.toUpperCase();
  }
</script>

<!-- bind after adding input listener -->
<input on:input={uppercase} bind:value={after} /> {after}

<!-- bind before adding input listener -->
<input bind:value={before} on:input={uppercase} /> {before}

The input.value accessed by the implicit event handler of the bind: directive depends on whether on:input handler gets called before or after.

If the implicit event handler of the bind: directive is called before the event handler, the bound value is the value of the input before applying the toUpperCase() transformation.

Although action: directive itself does not add event listener to the element, but it is possible to be added by the user code:

<script>
  let before = ''
  let after = '';
  function uppercaseAction(element) {
    function fn(event) {
      event.target.value = event.target.value.toUpperCase()
    }
    element.addEventListener('input', fn);
    return {
      destroy() {
        element.removeEventListener('input', fn);
      }
    };
  }
</script>

<!-- bind after adding action -->
<input use:uppercase bind:value={after} /> {after}

<!-- bind before adding action -->
<input bind:value={before} use:uppercase /> {before}

Although it is not officially documented, (I couldn’t find it on the docs), the order of declaring the directives on:, bind: and use: on an element does matter to provide a consistent behavior.

Try out the following example in the REPL:

<script>
  let checked;
  function onChange() {}
  function action() {}
</script>

<input
  type=checkbox
  bind:checked
  on:change={onChange}
  use:action
/>

Svelte REPL

Try reordering the bind:, on: and use: directives and see how it affects the output JS:

// ...
function create_fragment(ctx) {
  let input;
  let action_action;
  let dispose;

  return {
    c() { /* ... */ },
    m(target, anchor, remount) {
      // ...
      dispose = [// bind:checked listen(input, 'change', /*input_change_handler*/ ctx[1]), // on:change={onChange} listen(input, 'change', onChange), // use:action action_destroyer((action_action = action.call(null, input))), ]; },
    // ...
  };
}

If you are interested to learn more about ordering directives, the edge cases it fixed and the regression bugs it caused, you can start with this Github issue.

Closing Note

In this article, we explored how on:, bind: and use: directives work.

We first looked at how we can implement them without using any framework. After that, we walked through how Svelte compiles the directives into JavaScript.

We’ve also talked about how the order of declaring directives on an element matters.

If you wish to know more, follow me on Twitter.

I’ll post it on Twitter when the next part is ready, where I’ll be covering logic blocks, slots, context, and many others.

⬅ ⬅ Previously in Part 2.

The Svelte Compiler Handbook

Tan Li Hau — Sun, 05 Apr 2020 08:00:00 +0000

Who is this for?

Anyone who

is interested in the Svelte compilation process
wants to get started in reading Svelte source code

Overview

The Svelte compilation process can be broken down into 4-steps

Parsing source code into Abstract Syntax Tree (AST)
Tracking references and dependencies
Creating code blocks and fragments
Generate code

Which sums out by the following pseudocode:

const source = fs.readFileSync('App.svelte');

// parse source code into AST
const ast = parse(source);

// tracking references and dependencies
const component = new Component(ast);

// creating code blocks and fragments
const renderer =
  options.generate === 'ssr' ? SSRRenderer(component) : DomRenderer(component);

// Generate code
const { js, css } = renderer.render();

fs.writeFileSync('App.js', js);
fs.writeFileSync('App.css', css);

1. Parsing source code into AST

// parse source code into AST
const ast = parse(source);

The Svelte syntax is a superset of HTML. Svelte implements its own parser for the Svelte syntax, which handles:

HTML syntax <div>
Curly brackets { data }
Logic blocks {#each list as item}

The Svelte parser handles specially for <script> and <style> tags.

When the parser encounters a <script> tag, it uses acorn to parse the content within the tag. When the parser sees a <style> tag, it uses css-tree to parse the CSS content.

Besides, the Svelte parser differentiates instance script, <script>, and module script, <script context="module">.

The Svelte AST look like:

{
  html: { type: 'Fragment', children: [...] },
  css: { ... },
  instance: { context: 'default', content: {...} },
  module: { context: 'context', content: {...} },
}

You can try out the Svelte parser in ASTExplorer. You can find the Svelte parser under HTML > Svelte.

Where can I find the parser in the source code?

The parsing starts here, which the parser is implemented in src/compiler/parse/index.ts.

Where can I learn about parsing in JavaScript?

My previous article, "JSON Parser with JavaScript" introduces the terminology and guides you step-by-step on writing a parser for JSON in JavaScript.

If this is the your first time learning about parser, I highly recommend you to read that.

2. Tracking references and dependencies

// tracking references and dependencies
const component = new Component(ast);

In this step, Svelte traverses through the AST to track all the variable declared and referenced and their depedencies.

a. Svelte creates a `Component` instance.

The Component class stores information of the Svelte component, which includes:

HTML fragment, fragment
instance script and module script AST and their lexical scopes, instance_scope and module_scope
instance variables, vars
reactive variables, reactive_declarations
slots, slots
used variable names to prevent naming conflict when creating temporary variables
warnings and errors
compile options and ignored warnings

b. Traverse the instance script and module script AST

Component traverses the instance script and module script AST to find out all the variables declared, referenced, and updated within the instance script and module script.

Svelte identifies all the variables available before traversing the template. When encountering the variable during template traversal, Svelte will mark the variable as referenced from template.

c. Traverse the template

Svelte traverses through the template AST and creates a Fragment tree out of the template AST.

Each fragment node contains information such as:

- expression and dependencies

Logic blocks, {#if}, and mustache tags, { data }, contain expression and the dependencies of the expression.

- scope

{#each} and {#await} logic block and let: binding create new variables for the children template.

Svelte creates a different Fragment node for each type of node in the AST, as different kind of Fragment node handles things differently:

Element node validates the attribute, bindings, content and event handlers.
Slot node registers the slot name to the Component.
EachBlock node creates a new scope and tracks the key, index and the name of the list to be iterated.
...

d. Traverse the instance script AST

After traversing through the template, Svelte now knows whether a variable is ever being updated or referenced in the component.

With this information, Svelte tries make preparations for optimising the output, for example:

determine which variables or functions can be safely hoisted out of the instance function.
determine reactive declarations that does not need to be reactive

e. Update CSS selectors to make style declarations component scope

Svelte updates the CSS selectors, by adding .svelte-xxx class to the selectors when necessary.

At the end of this step, Svelte has enough information to generate the compiled code, which brings us to the next step.

Where can I find this in the source code?

You can start reading from here, which the Component is implemented in src/compiler/compile/Component.ts.

Where can I learn about traversing in JavaScript?

Bear with my shameless plug, my previous article, "Manipulating AST with JavaScript" covers relevant knowledge you need to know about traversing AST in JavaScript.

3. Creating code blocks and fragments

// creating code blocks and fragments
const renderer =
  options.generate === 'ssr' ? SSRRenderer(component) : DomRenderer(component);

In this step, Svelte creates a Renderer instance which keeps track necessary information required to generate the compiled output. Depending on the whether to output DOM or SSR code (see generate in compile options), Svelte instantiates different Renderer respectively.

DOM Renderer

DOM Renderer keeps track of a list of blocks and context.

A Block contains code fragments for generate the create_fragment function.

Context tracks a list of instance variables which will be presented in the $$.ctx in the compiled output.

In the renderer, Svelte creates a render tree out of the Fragment tree.

Each node in the render tree implements the render function which generate codes that create and update the DOM for the node.

SSR Renderer

SSR Renderer provide helpers to generate template literals in the compiled output, such as add_string(str) and add_expression(node).

Where can I find the `Renderer` in the source code?

The DOM Renderer is implemented in src/compiler/compile/render_dom/Renderer.ts, and you can check out the SSR Renderer code in src/compiler/compile/render_ssr/Renderer.ts.

4. Generate code

// Generate code
const { js, css } = renderer.render();

Different renderer renders differently.

The DOM Renderer traverses through the render tree and calls the render function of each node along the way. The Block instance is passed into the render function, so that each node inserts the code into the appropriate create_fragment function.

The SSR Renderer, on the other hand, relies on different node handlers to insert strings or expressions into the final template literal.

The render function returns js and css which will be consumed by the bundler, via rollup-plugin-svelte for rollup and svelte-loader for webpack respectively.

Svelte runtime

To remove duplicate code in the compiled output, Svelte provide util function which can be found in the src/runtime/internal, such as:

dom related utils, eg: append, insert, detach
scheduling utils, eg: schedule_update, flush
lifecycle utils, eg: onMount, beforeUpdate
animation utils, eg: create_animation

If you wish to know more, follow me on Twitter.

Forem: Tan Li Hau

2 ways to pass data into Svelte slots

1. Passing data from the current component

2. Passing data from the component you are using

Slot props for named slots

Reactive data

Reference

Explain Svelte slots like I'm five

What is a slot?

Named Slot

svelte:fragment

Slot fallback

Reference

2 amazing use case of tick() in Svelte that you must know

1. Waiting for reactive declared variables to get updated

2. Waiting for svelte to update the DOM elements

Bonus

Querying dynamic content created using {@html}

Restoring input cursor position after updating input value

7 Event Modifiers in Svelte You Must Know

Introducing the Event Modifiers!

1. preventDefault

2. stopPropagation

3. passive

4. nonpassive

5. once

6. capture

7. self

Event modifiers can be chained

Notes: The CSS Podcast #027 - "Houdini Series: Typed Object Model"

Podcast

Notes

CSS Typed Object Model (Typed OM)

computedStyleMap

attributeStyleMap

Types of CSSStyleValue

create CSSStyleValue

CSSImageValue

CSSKeywordValue

CSSNumericValue

CSSMathValue

CSSPositionValue

CSSTransformValue

CSSUnparsedValue

References

Notes: The CSS Podcast #026 - "Houdini Series: Properties & Values"

Podcast

Notes

CSS Houdini

Properties and Values API

2 ways to register houdini custom properties

Syntax

Multipliers

Combinators

References

Contributing to Svelte - Implement {#key}

Background

The motivation

Transitions for reactive data change

The implementation

Parsing

Tracking references and dependencies

Creating code blocks & fragments

Creating code for SSR

Generate code

A few other implementation consideration

The testing

Closing Notes

Compile Svelte in your head ({#if})

The {#if} block

The Vanilla JS

Implementating the if block

Refactor the code

The Compiled JS

The extra text node

Closing Note

Contributing to Svelte - Fixing issue #5012

Background

The bug

Verifying the bug

`svelte:fragment`

Querying dynamic content created using `{@html}`

The `{#if}` block

- the `{@html ...}` has no next element, and

The `on:`, `bind:` and `use:`

`on:` event handlers

`bind:` bindings

`use:` actions

`on:` directive

`bind:` directive

- In the u_p_date method, if the variable `checked` is updated, Svelte sets `input.checked` to the value of the variable `checked`.

`use:` directive

a. Svelte creates a `Component` instance.

Where can I find the `Renderer` in the source code?