Svelte

Reactivity in Svelte

Jul 26, 2021

7 min read

Reactivity in Svelte

Keeping your application in sync with its state is one of the most important features that a framework can provide. In this post, we'll learn about how reactivity works in Svelte, and avoid common issues when using it.

Let's start a new application to explain how it works.

npm init @vitejs/app

✔ Project name: · svelte-reactivity
✔ Select a framework: · svelte
✔ Select a variant: · svelte-ts

cd svelte-reactivity
pnpm install //use the package manager you prefer
pnpm run dev

We will remove everything we have in our App.svelte component an replace it with the following:

<!-- App.svelte -->
<script lang="ts">
	let language: 'es'|'en' = 'en';

	function toggleLanguage() {
		language = language === 'en' ? 'es' : 'en';
	}
</script>

<main>
	<p>{language}</p>
	<button on:click={toggleLanguage}>Toggle Language</button>
</main>

We added a button with an event handler responsible for toggling our variable with two values en and es. We can see that the value is updated every time we click the button.

In Svelte, the DOM is updated when an assignment is made. In this example, language is assigned with the result of language === 'en' ? 'es' : 'en'. Behinds the scenes, Svelte will take care of rerendering the value of language when the assignment happens.

If we take a look at the compiled code we will find this.

/* App.svelte generated by Svelte v3.38.3 */
// ...

function instance($$self, $$props, $$invalidate) {
	let language = "en";

	function toggleLanguage() {
		$$invalidate(0, language = language === "en" ? "es" : "en");
	}

	return [language, toggleLanguage];
}

// ...

We can see that our toggleLanguage function looks a bit different, wrapping the assignment with the $$invalidate method.

Let's make a few more changes to our file to see how assignment affects reactivity and rerendering.

<!-- App.svelte -->
<script lang="ts">
	let testArray = [0]

	function pushToArray(){
		testArray.push(testArray.length)
	}

	function assignToArray(){
		testArray = [...testArray, testArray.length]
	}
</script>
<main>
	<p>{testArray}</p>
	<button on:click={pushToArray}>Push To Array</button>
	<button on:click={assignToArray}>Assign To Array</button>
</main>

Whenever we click on the Assign To Array Button, the DOM is updated with the new value. When we try to get the same result by mutating the array, the DOM is not updated, but the app state is. We can verify that when we later click the Assignment button and the DOM is updated, showing the actual state of testArray.

Let's inspect the generated code once again.

function instance($$self, $$props, $$invalidate) {
	let testArray = [0];

	function pushToArray() {
		testArray.push(testArray.length);
	}

	function assignToArray() {
		$$invalidate(0, testArray = [...testArray, testArray.length]);
	}

	return [testArray, pushToArray, assignToArray];
}

If you compare both functions, we can now see that only the assignment will call the $$invalidate method, while the other one calls the expression as is.

This doesn't mean we cannot mutate arrays and force a rerender. We need to use an assignment after mutation to do it.

<!-- App.svelte -->
<script lang="ts">
	//...

	function pushToArray(){
		testArray.push(testArray.length)
		testArray = testArray
	}

	//...
</script>

Our complied function will be updated to:

function pushToArray() {
	testArray.push(testArray.length);
	$$invalidate(0, testArray);
}

which will update the DOM when called($$invalidate method wraps the expression, that is simplified to testArray instead of testArray = testArray)

Reactive Variables

Imagine our team decided that we need to add a second array where each value is squared. If we were doing it imperatively, this would mean we need to update the second array each time the first one changes. The previous example would look like this.

<!-- App.svelte -->
<script lang="ts">
	let testArray = [0]
	let squared = [0]

	function pushToArray(){
		testArray.push(testArray.length)
		testArray = testArray
		squared = testArray.map(value => value*value)
	}

	function assignToArray(){
		testArray = [...testArray, testArray.length]
		squared = testArray.map(value => value*value)
	}
</script>
<main>
	<p>{testArray}</p>
	<p>{squared}</p>
	<!-- ... -->
</main>

If we check the generated code again, we'll see that we are invalidating both arrays every time.

function pushToArray() {
	testArray.push(testArray.length);
	$$invalidate(0, testArray);
	$$invalidate(1, squared = testArray.map(value => value * value));
}

function assignToArray() {
	$$invalidate(0, testArray = [...testArray, testArray.length]);
	$$invalidate(1, squared = testArray.map(value => value * value));
}

Unfortunately, this approach has a problem. We need to keep track of every place where testArray is modified, and also update the squared array.

If we think about this problem reactively, we only need to listen to changes in testArray.

In Svelte, there's a special way to do this. Instead of declaring a variable with let, we will use $:. This is a labeled statement (it's valid JS), and it's used by the compiler to let it know that a reactive variable is being declared, and it depends on all the variables that are added to the expression. In our example:

<script lang="ts">
  let testArray = [0];
  $: squared = testArray.map(value => value * value)

  function pushToArray() {
    testArray.push(testArray.length);
    testArray = testArray;
  }

  function assignToArray() {
    testArray = [...testArray, testArray.length];
  }
</script>

Using this reactive approach, we need to handle changes to testArray exclusively. The compiler will detect that there's a dependency in testArray to calculate the actual value of squared.

If you run the app again, the same behavior is achieved.

How did this happen? Let's look at our compiled code.

	$$self.$$.update = () => {
		if ($$self.$$.dirty & /*testArray*/ 1) {
			$: $$invalidate(1, squared = testArray.map(value => value * value));
		}
	};

The internal property update is now assigned to a function that will check if the instance has changed, and that invalidate squared if the condition is met.

Every other reactive variable we add to our component will add a new block that will check if a dependency changed, and invalidate the declared variable. For example:

<script lang="ts">
  let testArray = [0];
  let multiplier = 5
  $: squared = testArray.map(value => value * value)
	// if ($$self.$$.dirty & /*testArray*/ 1) {
	//	 $: $$invalidate(1, squared = testArray.map(value => value * value));
	// }
  $: squaredTwice = squared.map(value => value * value)
	// if ($$self.$$.dirty & /*squared*/ 2) {
	//   $: squaredTwice = squared.map(value => value * value);
	// }
  $: multiplied: squaredTwice.map(value => value * multiplier)
	// if ($$self.$$.dirty & /*squaredTwice, multiplier*/ 34) {
	//   $: multiplied = squaredTwice.map(value => value * multiplier);
	// }

</script>
<!-- ... -->

The last declaration, however, depends on two variables, squareTwice and multiplier. You can tell by the comment in the if condition.

Our updated component now looks like this:

<script lang="ts">
  let testArray = [0];
  let multiplier = 5;

  $: squared = testArray.map((value) => value * value);
  $: squaredTwice = squared.map((value) => value * value);
  $: multiplied = squaredTwice.map((value) => value * multiplier);

  function pushToArray() {
    testArray.push(testArray.length);
    testArray = testArray;
  }

  function assignToArray() {
    testArray = [...testArray, testArray.length];
  }
</script>

<main>
  <p>{testArray}</p>
  <p>{squared}</p>
  <p>{squaredTwice}</p>
  <p>{multiplied}</p>
  <button on:click={pushToArray}>Push To Array</button>
  <button on:click={assignToArray}>Assign To Array</button>
  <button on:click={() => multiplier = multiplier + 1}>Multiplier</button>
</main>

I added a button to add 1 to multiplier to verify that the multiplied array is also depending on it.

Reactive Statements

Reactivity is not limited to variable declarations. Using the same $: pattern we can create reactive statements. For example, we could add an if statement or add a try-catch block.

Let's try the following:

<script lang="ts">
  //...
  let error = null;
  //...
  $: try {
    if (multiplier > 8) {
      throw 'boo';
    }
  } catch (e) {
    error = e;
  }
  //...
</script>

<main>
  <!-- ... -->
  {#if error}
    <p>{error}</p>
  {/if}
  <!-- ... -->
</main>

Looking at the generated code we can see the same pattern as before:

if ($$self.$$.dirty & /*multiplier*/ 2) {
	$: try {
		if (multiplier > 8) {
			throw "boo";
		}
	} catch(e) {
		$$invalidate(4, error = e);
	}
}

The compiler recognizes how the statement depends on changes to multiplier and that invalidating error is a possibility.

Store auto-subscription

A store is defined as an object that implements the following contract (at a minimum): store = { subscribe: (subscription: (value: any) => void) => (() => void), set?: (value: any) => void } Stores are beyond the scope of this post but they will make possible to listen for changes to a piece of your app state. Then, we can translate this event (when the store emits a new value) into an assignment that, as we mentioned before, will update our DOM. For example:

// stores.ts
import { writable } from 'svelte/store';
export const storeArray = writable([0]);

<!-- App.svelte -->
<script lang="ts">
  import { onDestroy } from 'svelte';
  import { storeArray } from './stores';

  let testArray;
  const unsubscribe = storeArray.subscribe((value) => {
    testArray = value;
  });
  function addValueToArray() {
    storeArray.update((value) => [...value, value.length]);
  }
  onDestroy(unsubscribe);
</script>

<main>
  <p>{testArray}</p>
  <button on:click={addValueToArray}>Add Value</button>
</main>

Whenever we update, or set our store, a new value will be emitted and assigned to testArray.

We can confirm that we are calling $$invalidate in the compiled code.

const unsubscribe = storeArray.subscribe(value => {
		$$invalidate(0, testArray = value);
	});

But there's another way to achieve this with auto-subscriptions.

Our component now becomes this:

<script lang="ts">
  import { storeArray } from './stores';
  function addValueToArray() {
    storeArray.update((value) => [...value, value.length]);
  }
</script>

<main>
  <p>{$storeArray}</p>
  <button on:click={addValueToArray}>Add Value</button>
</main>

Looking at auto subscriptions. There's no assignment in it, but our DOM is updated when we update the array. How is this achieved?

Let's analyze the output code:

function instance($$self, $$props, $$invalidate) {
	let $storeArray;
	component_subscribe($$self, storeArray, $$value => $$invalidate(0, $storeArray = $$value));

	function addValueToArray() {
		storeArray.update(value => [...value, value.length]);
	}

	return [$storeArray, addValueToArray];
}

We can see that we are calling component_subscribe with three parameters: the component, the store, and a callback function, which is invalidating our $storeArray variable.

If we go deeper and check what component_subscribe is doing underneath, we'll find the following:

export function subscribe(store, ...callbacks) {
	if (store == null) {
		return noop;
	}
	const unsub = store.subscribe(...callbacks);
	return unsub.unsubscribe ? () => unsub.unsubscribe() : unsub;
}

export function component_subscribe(component, store, callback) {
	component.$$.on_destroy.push(subscribe(store, callback));
}

... Which is doing the same as the original code.

It subscribes to the store, and returns a unsubscribe method (or an object with an unsubscribe method), and calls it when the component is destroyed. When a new value is emitted, the callback is executed ($$invalidate), assigning the emitted value to the auto-subscribe variable.

Common issues

Remember that we need an assignment to call $$invalidate mark the component instance as dirty and run all the checks. =, ++, --, +=, -= are all considered assignments.
When working with objects, the assignment must include the name of the variable referenced in the template. For example:

<script>
  let foo = { bar: { baz: 1 } };
  let foo2 = foo;
  function addOne() {
    foo2.bar.baz++;
  }
  function refreshFoo() {
    foo = foo;
  }
</script>
<p>foo: {JSON.stringify(foo, null, 2)}</p>
<p>foo2: {JSON.stringify(foo2, null, 2)}</p>

<button on:click={addOne}> add 1 </button>

<button on:click={refreshFoo}> Refresh foo </button>

When adding 1 to foo2.bar.baz the compiler only knows that it must update references to foo2 in the templates, but it will not update references to foo event if it changes too (they're the same object). When calling refreshFoo we are manually invalidating foo Reactivity_Svelte_07

when mutating arrays, be mindful of adding an assignment at the end to let the compiler know that it must update the template references.

Wrapping up

In general, whenever an assignment is made it will compile into an $$invalidate method that will mark the component as dirty and apply the required changes to the DOM. If there's any reactive variable (or statement) it will check if the component is marked as dirty and if any of its dependencies changed (because it has been invalidated), if that's the case then it will also invalidate it. Store auto subscription creates an assignment that invalidates the $ prepended variable when the store emits a new value.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

Ignacio Falk

I love to learn new things and share what I know. Mentor, Writer, Speaker Member of the local community

@flakolefluk @flakolefluk

JSR - The cross-platform package manager for ESM

JSR - The cross-platform package manager for ESM Move over NPM, there’s a new package manager in town. JSR is a new open-source package registry for JavaScript and TypeScript. This particular release has caught my attention, and I’m excited to explore if and where JSR fits into our overflowing ecosystem. Setting the stage The JSR website has a page called Why JSR? I want to explore the _why_ a little bit further. I think that the _why_ points to JSR potentially being the future of the JavaScript ecosystem. NPM and JavaScript modules If you’ve found yourself confused about publishing and consuming packages and modules in the modern ESM era, you’re not alone. When NodeJS was created, there was no standard for JS modules. Node introduced CommonJS modules, and NPM provided a way to publish and consume these modules in our applications. It’s been years now since ES Modules became a standard and we are still in a weird module purgatory with no clear end in sight. JSR represents a fresh start, free from the baggage of the Node and NPM ecosystems. JavaScript runtimes and interoperability New JavaScript runtimes are popping up every year. WinterCG (_Web-interoperable Runtimes Community Group)_ was started to improve interoperability for the various runtimes with some standard APIs. Node has made steps towards this goal, but it might never get all the way there and NPM is coupled pretty tightly to that ecosystem. JSR supports several runtimes (depending on the package). This is a huge opportunity for it to become the package manager for the ecosystem at large. See cross-runtime support section for more details. NPM Compatibility JSR doesn’t end up being a complete departure from NPM since it includes an NPM compatibility layer. The docs highlight some limitations and provide deeper technical details on how this piece works. The simple overview is that you can install and use packages from JSR to a Node/NPM based project. The packages will get added to your package.json and node_modules directory. About the same as any package installed from NPM. JSR Overview At a high level, JSR is very similar to NPM. You can search for packages on the website. You can publish packages to their registry, and you can download packages from it as well. We touched on the two major features that set it apart from NPM: It only supports ESModules, and it has cross-runtime support. In the rest of the article we’ll explore the essentials (package management) and also some other really great features that feel like are bringing the JS package management ecosystem up to speed with our modern workflows. Native TypeScript I have to say I’m not surprised by this feature, considering JSR was developed by the same people behind Deno (a runtime that supports TS natively). It’s a great feature. If you haven’t figured it out yet TypeScript is a big deal and doesn’t seem to be fading away anytime soon. So what exactly does TS support look like in a package manager, though? If your runtime supports TypeScript natively (like Deno) - it can consume the TS files in your package directly. For environments that don’t, it will automatically compile your code to JavaScript and package it with type declaration files (.d.ts). Pretty, stinking, cool. The docs include a page called “about slow types”. It is probably worth a read on its own ,but the TLDR is that JSR will analyze your TS code and penalize you in certain ways if you have some type code that it considers to be slow. On the page, it outlines exactly what these penalties are, as well as what it considers slow types to be. Slow types will also come into play when we get into package scoring later in the article. Packages The docs have a page dedicated to packages. It covers some important stuff like deleting packages, versioning, documentation, and publishing. We’ll touch on some of it with an emphasis on the things that are done differently or better than with NPM. jsr.json file jsr.json is a configuration file that specifies a name, version, and exports of a package. It doesn’t include a list of dependencies like you would have in a package.json file. This is a configuration file for a package to be published to JSR. JSR dependencies are defined in an import map file or a package.json file, depending on the runtime. Adding packages to a project Adding packages to your project will vary depending on your target runtime. Here’s an example of installing it for Deno and NPM using various package managers. For Deno, an import map entry is created. For NPM, it gets installed as an NPM package using the JSR NPM compatibility layer. ` If the runtime has native JSR support, you don’t need to explicitly install packages. You can important them using the jsr: scheme. ` As you can see semantic versioning is supported and works similarly to NPM. Publishing packages If you want to publish a package to JSR, there are many important rules you need to be aware of. I recommend reading “Publishing packages” before moving forward with this. The main things to note are: ESModules only, npm packages are supported, JSR packages are supported, and node APIs are supported. So there aren’t many constraints. You just need to understand how exactly to do these things. IE: how do I use NPM dependencies, how do the imports work, etc? Once you’ve got all that down, you will be ready to publish your first package to JSR 😃 Documentation JSR emphasizes quality package documentation. It’s one of the factors in their package scoring algorithm, which we will discuss shortly. The important parts of a package’s documentation include: * a README.md file * symbol documentation - functions, interfaces, classes, etc * module documentation - docs for each exported module in a package The symbol and module documentation are written using JSDoc. The JSR website generates some nice documentation based on these 3 pieces on your package page. This means you can understand a package's entire public API without ever leaving jsr.io. Browser support The cross-runtime support is amazing, but I was curious where the original JavaScript runtime fit (the browser). According to the documentation: “You can use JSR with any tool that supports ES modules, and either has native support for JSR or supports npm packages using node_modules.” Since modern web browsers support ES modules, I will count this as JSR support. From what I can tell, though, there is one caveat. To include a module on a web page, we need a URL to download it from. Can we publish our package to JSR and use it to load a module via a script tag? According to the JSR usage policy, no. The “Unacceptable use” section states: “It is not acceptable to use JSR as a CDN for serving assets directly to web applications in a browser, except for development purposes.” So, it seems that this is a no-go for now. We will probably need to wait a bit for CDN services like jsdelivr to pull packages from the JSR registry, similar to what they do with NPM currently. Other notable features We’ve covered the most important bits about package management, TS support, NPM compatibility, etc. But there are still a few unique features that add an extra bit of sparkle to JSR. Scoring We mentioned earlier that documentation plays a part in a scoring algorithm. JSR analyzes all of the packages published to its registry and assigns them a score based on certain criteria: documentation, best practices, discoverability, and compatibility. This score is shown with every package listed on the website. You can also add a shiny badge to your README if you’re particularly proud of something. It’s still early on, so it’s likely this will evolve as time goes on. It’s an interesting gimmick, at the very least! Summary I am excited to have a new cross-platform compatible package manager that only supports ESM. As useful as NPM has been all these years, it carries a lot of baggage from “the olden days”. JSR’s native TypeScript support and reliance on modern standards is a breath of fresh air. It feels like I can publish a simple package without much ceremony. I’m excited to release my first package to JSR soon :)...

Apr 12, 2024

6 mins

JSRJavaScript

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes Introduction: Next.js, a powerful React framework, offers two essential features - Parallel Routes and Intercepting Routes - that enable developers to create highly dynamic and seamless user experiences in their applications. In this blog post, we will explore both Parallel Routes and Intercepting Routes, highlighting their functionalities, use cases, and how they can be combined to enhance application routing. What are Parallel Routes? Parallel Routes in Next.js allow the rendering of multiple pages within a shared layout. Rather than navigating to a completely separate page, Parallel Routes enable the simultaneous rendering of different pages based on certain conditions such as user roles or tab navigation. By leveraging named slots, defined using the @folder convention, multiple pages can be seamlessly integrated into a single layout, enhancing user experience and reducing code duplication. How to Use Parallel Routes: To utilize Parallel Routes in Next.js, you must define named slots for the desired pages within your application's folder structure. These slots are then passed as props to a shared parent layout component. For example, consider a social networking application where two pages, feed and notifications, must be rendered within a common layout. You can define Parallel Routes using the following structure: ` The layout component in app/layout.js will accept the @feed and @notifications slots as props and render them alongside the children prop. Here's an example of the layout component: ` It's important to note that slots do not affect the URL structure and are not considered route segments. This means the URL would be /mypage/@feed/views for a route like /mypage/views since @feed is a slot. Also, to prevent the application from rendering nothing or throwing an error, we could use the default.tsx file: ` In this example, the default.tsx file specifies the default content (or fallback) to render when none of the named slots match the current route. It acts as a catch-all for routes without a corresponding slot. Some Use Cases: *Conditional Routes:* Parallel Routes can conditionally render routes based on certain conditions, such as user roles. For example, you can render a different dashboard page for admins and users. This can be achieved by creating a layout component specific to the dashboard and checking the user role to determine which slot to render. *Tab Groups:* You can utilize Parallel Routes to create tabbed navigation within a section. This is especially useful for analytics or multi-page views. Adding a layout inside a slot allows users to navigate between different pages within that slot independently. *Loading and Error UI:* Parallel Routes can be independently streamed, allowing you to define custom error and loading states for each route. This enables better control over the user experience by providing distinct feedback for different app sections. *Modals:* Parallel Routes can be combined with Intercepting Routes to create modals with shareable URLs, preserved context on refresh, and customized navigation behavior. By intercepting certain routes and rendering them within a modal component, you can create a seamless modal experience. Understanding Intercepting Routes: Intercepting Routes in Next.js allows you to load content from another route within the current layout without changing the URL or refreshing the page. Using the (..) Convention: Intercepting routes are defined using the (..) convention, which is similar to the relative path convention ../ but for route segments. The convention allows for matching segments on the same level (.), one level above (..), two levels above (..)(..), or from the root app directory (...). For example, to intercept the photo segment from within the feed segment, you can create a (..)photo directory. Integrating Intercepting Routes with Parallel Routes - Modals: One powerful use case for Intercepting Routes is creating modals, which can be combined with Parallel Routes to solve common challenges such as making the modal content shareable through a URL, preserving context on page refresh, and handling backward and forward navigation. Let's make an example: ` Our folder structure will be: In this example, when a user clicks on a photo within the /gallery page, the route /photo/:photoId will be intercepted and rendered within the (..)photo directory, overlaying the gallery content. This means that the photo route is only one segment level higher despite being two file-system levels higher. In the example above, the path to the photo segment can use the (..) matcher since @modal is a slot and not a segment. Common Use Cases - Beyond Modals: Intercepting Routes can also be utilized in other scenarios. Some examples include opening a login modal in a top navbar while having a dedicated /login page, or opening a shopping cart in a side modal for better accessibility or creating wizards or multi-step forms within a single page. The possibilities are endless. Conclusion Next.js Parallel and Intercepting Routes offer powerful methods for enhancing the routing capabilities of your applications. With Parallel Routes, multiple pages can be seamlessly integrated within a shared layout, simplifying navigation and enhancing user experience. By incorporating Intercepting Routes, you can create dynamic overlays like modals, enabling content from different routes to be displayed within the current layout. By leveraging these features, you can unlock exciting possibilities and take your Next.js applications to new heights of user engagement....

Apr 5, 2024

3 mins

NextJSJavaScript

Declarative Canvas with Svelte

The element and the Canvas API let us draw graphics via JavaScript. However, its Imperative API can be converted into a Declarative one using Svelte. The technique to achieve this will require you to use what is sometimes called _Renderless Components_. Renderless Components In Svelte, all the sections of a .svelte file are optional, including the template. This allows us to create a component that will not be rendered, but can contain some logic in the section. Let's create a new project. I'll be using Vite and Svelte for this tutorial. ` Now that our project is ready, let's create a new component. ` We will be printing a message to the console when the component is initialized. Let's see how it works by making some changes to the entry point of our application. ` If we start our server and open the developer tools in our browser, we will see the message printed. It's working. Note that this component, even if it doesn't have a template, still behaves as a regular component instance, and you will still have access to the component Lifecycle methods. Let's test it. ` We added a second message to be shown after the component is mounted. Both messages are now printed in the expected order. This means that we can use our Renderless Component just as any other Svelte Component. Let's revert the changes to the main.ts file, and "render" the component inside the App component. ` ` Finally, let's also modify our Renderless component to log more meaningful messages. ` It's important to note the order of initialization and mounting of the components. This will be important when we create our Canvas and _renderless_ Components. There's a third way to mount our component and that's passing it as a child of another component. This is also called content projection. And the way that we do this is by using slots. Let's create a container component that will render elements in a slot. I will also add more elements that will live along with the element. ` Let's also add a _prop_ to the Renderless component to add some kind of identifier to it. ` Finally, in our App, we update the template to use the container, and pass multiple instances of Renderless to it. ` Now, we can see the rendered Container and the _renderless_ components logging when they are initialized and mounted. Now that we've learned about renderless components, let's use them with the element. and the Canvas API The canvas element cannot contain any children, except for a fallback element to render. Anything that you may want to render inside the canvas must be done using its imperative API. Let's create a new Canvas component and render an empty canvas. ` Update the App component to import and use Canvas. ` If we open the browser dev tools, we should see a canvas element rendered now. Rendering elements inside canvas As mentioned previously, we cannot add elements to draw inside our canvas. We have to use the API to do it. To get a reference to the element, we will use the bind:this directive. It's important to understand that, to use the API, we need the element to be available. This means that we will have to draw after the component is mounted. ` Now let's draw a line (I'm removing all the logging from the component for clarity). ` To draw, we need the canvas context. So we must do it after mounting the component. Then, we can start drawing using the canvas API. If we want to add a second line, we would have to add a new block of code. ` We can see that we are starting to add more and more code to our component just by drawing simple shapes. This can get out of hand quickly. We can create helper functions to draw the lines. ` The code becomes more readable, but we are still delegating all the responsibility to the Canvas component, which will translate into having a very complex component. We can avoid this by using _renderless_ components and the Context API. We know a few things so far: * We require the Canvas context to draw. * We can get the context after the component is mounted. * Child components are mounted before the parent component. * Parent components are initialized before child components. * We can use to mount child components. We want to split our component into multiple. For this example, we want the Line component to draw itself. Canvas and Line are coupled. A Line component cannot be drawn without a Canvas, and it needs the canvas context. The problem is that the context is not available when we mount the Child component (Line is mounted before Canvas), so we need a different approach. Instead of passing the context to draw itself, we will let the parent component know that a child component needs to be drawn. We'll communicate the Canvas and Line components using Context. Context is a way for two or more components to communicate. Context can only be set or retrieved during initialization, which is what we need in our case. Remember that Canvas is initialized before our Line component. Let's start by moving the line rendering to its own component. I will also move some types to their own file to be shared across components. ` ` This is very similar to what we had in our Canvas component, but abstracted to a reusable component. Now we need a Communicate Canvas and Line components. Our Canvas will work as the orchestrator of all the rendering. It will initialize all the Child components, gather the rendering functions, and draw them when required. ` The first thing to note is that our template has changed and now we have a element beside our canvas. It will be used to mount any children that we pass into our canvas-- in our case, the Line components. These will not add any HTML element. In the script section, we added an array to hold all the render functions to draw. We also set a new context. This has to be done during initialization. Our Canvas is initialized before Line, so we set two methods here. These are methods to add and remove a function from our array that holds them. Then any Child component can have access to this context, and call its methods. That's exactly what we'll do next in the Line component. ` We register the function using the context previously set by Canvas when we mount this component. We could do it on initialization too because we know that context will be available anyway. But I prefer doing it after the component is mounted. And when the element is destroyed, it removes itself from the list of rendering functions. Finally, let's update our App to use the new Canvas and Line components. ` We've successfully updated our Canvas component to use a declarative approach. A few things are missing though. We are only drawing once when the Canvas component is mounted. We need to make the canvas render frequently to update itself when changes happen (unless you only want to render once). Note that we would have to do it with or without the approach we've taken. And it's a common way of updating the canvas contents. ` We achieve this rerendering of the canvas using the requestAnimationFrame method. The callback passed in will be run before the browsers' repaint. First, we create a new variable to assign the current frameId (required for canceling the animation). Then, when we mount the component, we invoke requestAnimationFrame and assign the returned id to our variable. So far, the end result is as before. The difference is now in our draw function that will request a new animation frame each time after being drawn. We will also clear our canvas by default. Otherwise, when we are animating, each frame would be drawn on top of each other (This might be the desired effect. In that case the clearFrame prop can be set to false). Our canvas will update each frame until we destroy our component and cancel any current animation using the id previously stored. Adding more features The basic functionality for the components is working, but we may want to add more features. For this example, we will be exposing two events: onmousemove and onmouseleave. To do this, we need to add a few things two our Canvas component. In the template, change the canvas element to this: ` Now, the events can be handled in our App: ` Svelte is responsible for updating the end position of the line. But our Canvas component is the one used to update the canvas content (using requestAnimationFrame). Wrapping up I hope this tutorial helps you as an introduction to use canvas in Svelte, but also to understand how we can turn a library with an Imperative API into a more declarative one. There are a few examples of these ideas with more complex examples using a similar approach, like svelte-cubed or svelte-leaflet. From the svelte-cubed docs: This ... ` becomes... ` We just scratched the surface of the Canvas API, but you can extend it for your own needs, or even create a library for it!...

Jul 21, 2022

8 mins

Svelte

Transforming Auth in an AI World with Rod Boothby

In today's digital landscape, the need for secure identity verification has become paramount. With the increasing risks of personal data exposure and the rise of sophisticated cyber threats aided by Artificial Intelligence, it is crucial to adopt robust verification processes to protect individuals and organizations alike. In a recent discussion with Rod Boothby, CEO of ID Partner Systems, the significance of trusted institutions for identity verification was emphasized, particularly the efficiency of bank-based ID verification over traditional methods. One of the key takeaways from the conversation was the importance of continuous authentication. As technology advances, so do the methods employed by cybercriminals. Deepfake technology, for instance, poses a significant threat to identity verification systems. To combat this, tighter security measures and continuous authentication are essential. By constantly verifying and validating user identities, organizations can stay one step ahead of potential fraudsters. Rod Boothby also highlighted the need for a developer-focused approach to identity verification. By providing developers with the tools and resources they need, companies like ID Partner Systems aim to streamline the verification process and enhance security. This approach not only ensures a more efficient experience for users but also allows for the integration of behavioral biometrics, which can further strengthen the verification process. Download this episode here....

Apr 22, 2024

1 min

Engineering Leadership

Reactivity in Svelte

Reactivity in Svelte

Reactive Variables

Reactive Statements

Store auto-subscription

Common issues

Wrapping up

Ignacio Falk

You might also like

JSR - The cross-platform package manager for ESM

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes

Declarative Canvas with Svelte

Transforming Auth in an AI World with Rod Boothby

You might also like

JSR - The cross-platform package manager for ESM

Maximizing Routing Flexibility with Next.js Parallel and Intercepting Routes

Declarative Canvas with Svelte

Transforming Auth in an AI World with Rod Boothby