Javascript

Web Components with Svelte

Aug 9, 2021

5 min read

Web Components with Svelte

Svelte is a great framework for building applications, but did you know you can create custom elements and web components with it?

In this post, we'll learn how to create a Svelte component, export it as a custom element, and use it. We'll also learn about limitations when doing it.

Developing

Let's start a new project to build our components.

npm init vite

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

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

For this example, we will not be building a Svelte application, but we will need at least a demo page to test all our web components.

We can delete the src/App.svelte file and modify the file located at main.ts to export the files in our library folder, instead of mounting our application.

// src/main.ts
export * from './lib/Counter.svelte'

Then, we need to give a tag to our web component. To achieve this, we need to add a special Svelte element to our component.

<script lang="ts">
  let count: number = 0
  const increment = () => {
    count += 1
  }
</script>

<!--Add this line to your web component-->
<svelte:options tag="my-counter" />

<button on:click={increment}>
  Clicks: {count}
</button>

<style>
  button {
    font-family: inherit;
    font-size: inherit;
    padding: 1em 2em;
    color: #ff3e00;
    background-color: rgba(255, 62, 0, 0.1);
    border-radius: 2em;
    border: 2px solid rgba(255, 62, 0, 0);
    outline: none;
    width: 200px;
    font-variant-numeric: tabular-nums;
    cursor: pointer;
  }

  button:focus {
    border: 2px solid #ff3e00;
  }

  button:active {
    background-color: rgba(255, 62, 0, 0.2);
  }
</style>

The assigned tag is the one that will be used later as a regular HTML element. For this component: <my-counter></my-counter>

Note: You can also set tag={null} and let the consumer define the tag.

// ...
customElements.define('my-counter', Counter);

It's time to update our demo page to use the web component that will be generated.

<!-- index.html -->

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <link rel="icon" href="/favicon.ico" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Svelte + TS + Vite App</title>
  </head>
  <body>
    <my-counter></my-counter>
    <script type="module" src="/src/main.ts"></script>
  </body>
</html>

I removed the <div id="app"> because we will not be using it. Then, I added our custom element tag to the body of the site.

Finally, we need to tell the compiler that we want to compile our Svelte components as custom elements.

Go to vite.config.js and update it like this:

import { defineConfig } from 'vite';
import { svelte } from '@sveltejs/vite-plugin-svelte';

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [
    svelte({
      compilerOptions: {
        customElement: true,
      },
    }),
  ],
});

Let's run our application (pnpm run dev). You should be able to see our web component in action.

It works!

Now, let's create a second web component.

I'll add a clock that will display the current time.

<!-- lib/Clock.svelte -->
<svelte:options tag="my-clock" />

<script lang="ts">
  import { onMount, onDestroy } from 'svelte';
  let date = new Date().toLocaleTimeString();
  let interval;

  onMount(() => {
    interval = setInterval(() => {
      date = new Date().toLocaleTimeString()
    }, 1000);
  });

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

<span>{date|| '' }</span>

<style>
  span {
    font-family: inherit;
    font-size: inherit;
    padding: 1em 2em;
    color: #ff3e00;
    background-color: rgba(255, 62, 0, 0.1);
    border-radius: 2em;
    border: 2px solid rgba(255, 62, 0, 0);
    outline: none;
    width: 200px;
    font-variant-numeric: tabular-nums;
    cursor: pointer;
  }

  span:active {
    background-color: rgba(255, 62, 0, 0.2);
  }
</style>

We should not forget to export it in our main.ts file.

export * from './lib/Counter.svelte'
export * from './lib/Clock.svelte'

And finally, use it in our index.html file.

<!DOCTYPE html>
<html lang="en">
<!-- ... -->
  <body>
    <my-counter></my-counter>
    <my-clock></my-clock>
    <script type="module" src="/src/main.ts"></script>
  </body>
</html>

Let's run our application, and see the result.

Building

We can keep adding as many web components as we want, but let's inspect our build output.

pnpm run build

vite v2.4.3 building for production...
✓ 6 modules transformed.
dist/index.html                  0.46kb
dist/assets/index.fdfcd12f.js    1.99kb / brotli: 0.67kb
dist/assets/vendor.4be80997.js   5.67kb / brotli: 2.13kb

Our components are bundled together (index.*.js), and the common code is in vendor.*.js. This might be a bit unfortunate if you want to distribute this as a library.

So let's analyze our options:

Bundle our library

If we want to create a single file for our output, we can use the lib option in our vite config.

Let's create a new config file vite.lib.config.js

import { defineConfig } from 'vite'
import { svelte } from '@sveltejs/vite-plugin-svelte'

// https://vitejs.dev/config/
export default defineConfig({
  build:{
    lib:{
      entry: './src/main.ts',
      name: 'MyLibrary',
    }
  },
  plugins: [svelte({
    compilerOptions:{
      customElement: true
    }
  })]
})

Now, we need to run our build process with the right config file.

pnpm run build -- -c=vite.lib.config.js

vite v2.4.3 building for production...
✓ 5 modules transformed.
dist/svelte-web-components.es.js   7.37kb / brotli: 2.60kb
dist/svelte-web-components.umd.js   7.46kb / brotli: 2.64kb

By default, the build.lib options will bundle your library in two formats: es and umd. You can configure it by adding the formats property to the lib settings. Available options are: 'es' | 'cjs' | 'umd' | 'iife'

Everything split

A third option would be to build everything as an independent web component, and a shared code file.

Let's create a different config file for this vite.split.config.js.

import { defineConfig } from 'vite';
import { svelte } from '@sveltejs/vite-plugin-svelte';

// https://vitejs.dev/config/
export default defineConfig({
  build:{
    rollupOptions: {
      input: ['./src/lib/Counter.svelte', './src/lib/Clock.svelte'],
    }
  },
  plugins: [
    svelte({
      compilerOptions: {
        customElement: true,
      },
    })
  ]
});

The output of this build would look like this:

pnpm run build -- -c=vite.split.config.js

vite v2.4.3 building for production...
✓ 4 modules transformed.
dist/assets/Counter.be2b21b7.js   1.03kb / brotli: 0.52kb
dist/assets/Clock.ca5b7224.js     1.09kb / brotli: 0.53kb
dist/assets/vendor.4be80997.js    5.67kb / brotli: 2.13kb

As you can see, we now have our counter and clock as independent chunks, and both depend on vendor.*.js

You can be specific on how many chunks you want, and what to bundle together or not.

Working with regular Svelte components and custom elements in the same project

When a project is set up to compile to web components, it will try to compile every .svelte file, including your App.svelte file, which may not be what you want.

Let's create a new project, and set it up to work with Svelte components along with other components that will be compiled into custom elements.

npm init vite

✔ Project name: · svelte-web-components-mix
✔ Select a framework: · svelte
✔ Select a variant: · svelte-ts

cd svelte-web-components
pnpm install
pnpm run dev

I will copy the Clock.svelte file from the previous project, and leave the Counter as it is.

We have a problem now. We cannot compile the clock as a custom element, and if we try to do it by modifying the config, the compiler will complain that our App and Counter do not have tags to be compiled.

Luckily, we can have different settings for different files.

// vite.config.js

import { defineConfig } from 'vite'
import { svelte } from '@sveltejs/vite-plugin-svelte'

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [
    svelte({
      exclude: ['./src/lib/Clock.svelte']
    }),
    svelte({
      exclude: ['./src/App.svelte', './src/lib/Counter.svelte'],
      compilerOptions: {
        customElement: true,
      }
    })
  ]
})

As you can see, we set up the Svelte plugin twice, and exclude the files that we need to.

Finally, we will update our App.svelte file to include our Clock custom element, and use it.

<!-- App.svelte -->
<script lang="ts">
  import Counter from './lib/Counter.svelte'
  import './lib/Clock.svelte'
</script>

<main>
  <Counter />
  <my-clock></my-clock>
</main>

If we run our application now, and inspect the document, we will confirm that we are using a web component for the clock along the compiled counter.

Things to consider when building custom elements

There are some limitations/features of custom elements that work differently when working with web components

To prevent props from being accessed from the DOM, add accessors={false} to the svelte:options element
Use a regular CustomEvent instead of the usual createEventDispatcher method from Svelte when emitting from a web component. Add composed:true to cross the Shadow DOM boundaries

<script>
function onClick(e) {
    e.target.dispatchEvent(new CustomEvent('message', {detail:{text:'Hello'}, composed:true}))
}
</script>

<button on:click={onClick} bind:this={buttonEl}>click me</button>

Some browsers do not support them. (Polyfills are required)
Shadow DOM is not available server-side.
Styles are encapsulated and not scoped. External/global styles will not be applied.
In the DOM, slotted content renders eagerly.

This means that it will be added even if it's not shown.

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

Avoid using slotted content inside #each blocks, as it will not be rerendered. As a general rule, avoid putting a <slot></slot> inside a template modifier as it will not work as expected.

Final thoughts

As you can see, there are plenty of options for developing and bundling your app and web components.

You can find a repo with the final code here.

I hope this post will help you explore what you can do with Svelte, and custom elements.

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

How to create and use custom GraphQL Scalars

How to create and use custom GraphQL Scalars In the realm of GraphQL, scalars form the bedrock of the type system, representing the most fundamental data types like strings, numbers, and booleans. As explored in our previous post, "Leveraging GraphQL Scalars to Enhance Your Schema," scalars play a pivotal role in defining how data is structured and validated. But what happens when the default scalars aren't quite enough? What happens when your application demands a data type as unique as its requirements? Enter the world of custom GraphQL scalars. These data types go beyond the conventional, offering the power and flexibility to tailor your schema to precisely match your application's unique needs. Whether handling complex data structures, enforcing specific data formats, or simply bringing clarity to your API, custom scalars open up a new realm of possibilities. In this post, we'll explore how to understand, create, and effectively utilize custom scalars in GraphQL. From conceptualization to implementation, we'll cover the essentials of extending your GraphQL toolkit, empowering you to transform abstract ideas into concrete, practical solutions. So, let's embark together on the journey of understanding and utilizing custom GraphQL scalars, enhancing and expanding the capabilities of your GraphQL schema. Understanding Custom Scalars Custom scalars in GraphQL extend beyond basic types like String or Int, allowing data to be defined, validated, and processed more precisely. They're instrumental when default types don't quite capture the complexity or specificity of the data, such as with specialized date formats or unique identifiers. The use of custom scalars brings several benefits: * Enhanced Clarity: They offer a clearer representation of what data looks like and how it behaves. * Built-in Validation: Data integrity is bolstered at the schema level. * Flexibility: They can be tailored to specific data handling needs, making your schema more adaptable and robust. With this understanding, we'll explore creating and integrating custom scalars into a GraphQL schema, turning theory into practice. Creating a Custom Scalar Defining a Custom Scalar in TypeScript: Creating a custom scalar in GraphQL with TypeScript involves defining its behavior through parsing, serialization, and validation functions. * Parsing: Transforms input data from the client into a server-understandable format. * Serializing: Converts server data back to a client-friendly format. * Validation: Ensures data adheres to the defined format or criteria. Example: A 'Color' Scalar in TypeScript The Color scalar will ensure that every color value adheres to a valid hexadecimal format, like #FFFFFF for white or #000000 for black: ` In this TypeScript implementation: * validateColors: a function that checks if the provided string matches the hexadecimal color format. * parseValue: a method function that converts the scalar’s value from the client into the server’s representation format - this method is called when a client provides the scalar as a variable. See parseValue docs for more information * serialize: a method function that converts the scalar’s server representation format to the client format, see serialize docs for more information * parseLiteral: similar to parseValue, this method function converts the scalar’s value from the client to the server’s representation format. Still, this method is called when the scalar is provided as a hard-coded argument (inline). See parseLiteral docs for more information In the upcoming section, we'll explore how to incorporate and validate these custom scalars within your schema, ensuring they function seamlessly in real-world scenarios. Integrating Custom Scalars into a Schema Incorporating the 'Color' Scalar After defining your custom Color scalar, the next crucial step is effectively integrating it into your GraphQL schema. This integration ensures that your GraphQL server recognizes and correctly utilizes the scalar. Step-by-Step Integration 1. Add the scalar to Type Definitions: Include the Color scalar in your GraphQL type definitions. This inclusion informs GraphQL about this new scalar type. 2. Resolver Mapping: Map your custom scalar type to its resolver. This connection is key for GraphQL to understand how to process this type during queries and mutations. ` 1. Use the scalar: Update your type to use the new custom scalar ` Testing the Integration With your custom Color scalar integrated, conducting thorough testing is vital. Ensure that your GraphQL server correctly handles the Color scalar, particularly in terms of accepting valid color formats and rejecting invalid ones. For demonstration purposes, I've adapted a creation mutation to include the primaryColor field. To keep this post focused and concise, I won't detail all the code changes here, but the following screenshots illustrate the successful implementation and error handling. Calling the mutation (createTechnology) successfully: Calling the mutation with forced fail (bad color hex): Conclusion The journey into the realm of custom GraphQL scalars reveals a world where data types are no longer confined to the basics. By creating and integrating scalars like the Color type, we unlock precision and specificity in our GraphQL schemas, which significantly enhance our applications' data handling capabilities. Custom scalars are more than just a technical addition; they testify to GraphQL's flexibility and power. They allow developers to express data meaningfully, ensuring that APIs are functional, intuitive, and robust. As we've seen, defining, integrating, and testing these scalars requires a blend of creativity and technical acumen. It encourages a deeper understanding of how data flows through your application and offers a chance to tailor that experience to your project's unique needs. So, as you embark on your GraphQL journey, consider the potential of custom scalars. Whether you're ensuring data integrity, enhancing API clarity, or simply making your schema a perfect fit for your application, the possibilities are as vast as they are exciting. Embrace the power of customization, and let your GraphQL schemas shine!...

Apr 10, 2024

5 mins

GraphQLJavaScript

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 Platform Engineering Through Chargeback Programs with Shuchi Mittal

Shuchi Mittal, the Head of Cloud enablement at Honeywell, discusses how she as a leader in platform engineering has been able to transform internal platform engineering teams at other organizations by providing teams with value-added services, and how they effectively managed costs. She talks about how to treat these teams as customers, and delivering services that meet the customer needs, but also charging them for their usage. By providing policy-compliant infrastructure and unique services tailored to their requirements, platform engineering teams can showcase their commitment to supporting the success of other teams within an organization. This approach not only fosters trust but also positions platform engineering as a strategic partner rather than just a service provider. By going beyond the basic infrastructure provisioning, the platform engineering team can offer services that help development and product teams streamline their processes and improve efficiency. Shuchi shares her work at Fiserv where she implemented a chargeback system to track usage and costs effectively, incentivizing better development practices. This not only helped in managing costs but also encouraged teams to optimize their resource utilization, leading to improved overall efficiency and more easily scalable systems. Her platform engineering team recognized the importance of effectively managing financial aspects to secure upfront investment for product development. By implementing a billing system based on gigabyte hours, they aligned costs with usage, enabling teams to have a clear understanding of their resource consumption. This approach not only provided transparency but also incentivized teams to adopt cost-effective practices. By strategically managing financial aspects, the platform engineering team gained the trust of stakeholders and secured the necessary resources to drive innovation and deliver value to the organization. Shuchi’s journey of platform engineering serves as a valuable example of how a team can transition from being a basic service provider to becoming an innovation partner within an organization. By building trust, offering value-added services, and strategically managing financial aspects, the platform engineering team successfully elevated their role and became a strategic enabler of innovation. Download this episode here....

Apr 16, 2024

2 mins

Engineering LeadershipSoftware Engineering

Web Components with Svelte

Web Components with Svelte

Developing

Building

Bundle our library

Everything split

Working with regular Svelte components and custom elements in the same project

Things to consider when building custom elements

Final thoughts

Ignacio Falk

You might also like

JSR - The cross-platform package manager for ESM

How to create and use custom GraphQL Scalars

Declarative Canvas with Svelte

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal

You might also like

JSR - The cross-platform package manager for ESM

How to create and use custom GraphQL Scalars

Declarative Canvas with Svelte

Transforming Platform Engineering Through Chargeback Programs with Shuchi Mittal