Net Parts Get rid of JavaScript Framework Lock-in

2023-11-27 10:41:35

We’ve seen loads of nice posts about net parts currently.
Many have targeted on the burgeoning HTML web components HTML web components Don’t replace. Augment. adactio.com/journal/20618 sample, which eschews shadow DOM in favor of progressively enhancing present markup.
There’s additionally been dialogue — together with this post by yours truly Web Components Will Outlive Your JavaScript Framework | jakelazaroff.com If we’re building things that we want to work in five or ten or even 20 years, we need to avoid dependencies and use the web with no layers in between. jakelazaroff.com/words/web-components-will-outlive-your-javascript-framework/ — about totally changing JavaScript frameworks with net parts.

These aren’t the one choices, although.
You may also use net parts in tandem with JavaScript frameworks.
To that finish, I need to speak about a key profit that I haven’t seen talked about as a lot: net parts can dramatically loosen the coupling of JavaScript frameworks.

To show it, we’re going to do one thing kinda loopy: construct an app the place each single part is written with a special framework.

It in all probability goes with out saying that you shouldn’t construct an actual app like this!
However there are legitimate causes for mixing frameworks.
Perhaps you’re progressively migrating from React to Vue.
Perhaps your app is constructed with Strong, however you need to use a third-party library that solely exists as an Angular part.
Perhaps you need to use Svelte for a couple of “islands of interactivity” in an in any other case static web site.

Right here’s what we’re going to create: a easy little todo app based mostly loosely on TodoMVC TodoMVC Helping you select an MV* framework – Todo apps for Backbone.js, Ember.js, AngularJS, Spine and many more todomvc.com .

As we construct it, we’ll see how net parts can encapsulate JavaScript frameworks, permitting us to make use of them with out imposing broader constraints on the remainder of the applying.

What’s a Net Element?

In case you’re not aware of net parts, right here’s a short primer on how they work.

First, we declare a subclass of HTMLElement in JavaScript. Let’s name it MyComponent:

class MyComponent extends HTMLElement {
  constructor() {
    tremendous();
    this.shadow = this.attachShadow({ mode: "open" });
  }

  connectedCallback() {
    this.shadow.innerHTML = `
      <p>Howdy from an online part!</p>
      <model>
        p {
          colour: pink;
          font-weight: daring;
          padding: 1rem;
          border: 4px strong pink;
        }
      </model>
    `;
  }
}

That decision to attachShadow within the constructor makes our part use the shadow DOM Using shadow DOM – Web APIs | MDN An important aspect of custom elements is encapsulation, because a custom element, by definition, is a piece of reusable functionality: it might be dropped into any web page and be expected to work. So it’s important that code running in the page should not be able to accidentally break a custom element by modifying its internal implementation. Shadow DOM enables you to attach a DOM tree to an element, and have the internals of this tree hidden from JavaScript and CSS running in the page. developer.mozilla.org/en-US/docs/Web/Web_Components/Using_shadow_DOM , which encapsulates the markup and kinds inside our part from the remainder of the web page.
connectedCallback is known as when the net part is definitely related to the DOM tree, rendering the HTML contents into the part’s “shadow root”.

This foreshadows how we’ll make our frameworks work with net parts.¹
We usually “connect” frameworks to a DOM factor, and let the framework take over all ancestors of that factor.
With net parts, we will connect the framework to the shadow root, which ensures that it will probably solely entry the part’s “shadow tree”.

Subsequent, we outline a customized factor title for our MyComponent class:

customElements.outline("my-component", MyComponent);

At any time when a tag with that customized factor title seems on the web page, the corresponding DOM node is definitely an occasion of MyComponent!

<my-component></my-component>
<script>
  const myComponent = doc.querySelector("my-component");
  console.log(myComponent instanceof MyComponent); 
</script>

Test it out:

There’s extra to net parts, however that’s sufficient to get you thru the remainder of the article.

Scaffolding Structure

The entrypoint of our app can be a React part.² Right here’s our humble begin:


export default perform TodoApp() {
  return <></>;
}

We might begin including components right here to dam out the fundamental DOM construction, however I need to write one other part for that to point out how we will nest net parts in the identical approach we nest framework parts.

Most frameworks assist composition through nesting like regular HTML components.
From the surface, it normally appears to be like one thing like this:

<Card>
  <Avatar />
</Card>

On the within, there are a couple of ways in which frameworks deal with this.
For instance, React and Strong provide you with entry to these youngsters as a particular youngsters prop:

perform Card(props) {
  return <div class="card">{props.youngsters}</div>;
}

With net parts that use shadow DOM, we will do the identical factor utilizing the <slot> element <slot>: The Web Component Slot element – HTML: HyperText Markup Language | MDN The <slot> HTML element—part of the Web Components technology suite—is a placeholder inside a web component that you can fill with your own markup, which lets you create separate DOM trees and present them together. developer.mozilla.org/en-US/docs/Web/HTML/Element/slot . When the browser encounters a <slot>, it replaces it with the kids of the net part.

<slot> is definitely extra highly effective than React or Strong’s youngsters.
If we give every slot a title attribute, an online part can have a number of <slot>s, and we will decide the place every nested factor goes by giving it a slot attribute matching the <slot>’s title.

Let’s see what this appears to be like like in observe.
We’ll write our structure part utilizing Solid SolidJS Solid is a purely reactive library. It was designed from the ground up with a reactive core. It’s influenced by reactive principles developed by previous libraries. www.solidjs.com :


import { render } from "solid-js/net";

perform TodoLayout() {
  return (
    <div class="wrapper">
      <header class="header">
        <slot title="title" />
        <slot title="filters" />
      </header>
      <div>
        <slot title="todos" />
      </div>
      <footer>
        <slot title="enter" />
      </footer>
    </div>
  );
}

customElements.outline(
  "todo-layout",
  class extends HTMLElement {
    constructor() {
      tremendous();
      this.shadow = this.attachShadow({ mode: "open" });
    }

    connectedCallback() {
      render(() => <TodoLayout />, this.shadow);
    }
  }
);

There are two components to our Strong net part: the net part wrapper on the high, and the precise Strong part on the backside.

Crucial factor to note in regards to the Strong part is that we’re utilizing named <slot>s as an alternative of the youngsters prop.
Whereas youngsters is dealt with by Strong and would solely allow us to nest different Strong parts, <slot>s are dealt with by the browser itself and can allow us to nest any HTML factor — together with net parts written with different frameworks!

The net part wrapper is fairly much like the example above.
It creates a shadow root within the constructor, after which renders the Strong part into it within the connectedCallback methodology.

Word that this isn’t an entire implementation of the net part wrapper!
On the very least, we’d in all probability need to outline an attributeChangedCallback method Using custom elements – Web APIs | MDN One of the key features of web components is the ability to create custom elements: that is, HTML elements whose behavior is defined by the web developer, that extend the set of elements available in the browser. developer.mozilla.org/en-US/docs/Web/API/Web_Components/Using_custom_elements#responding_to_attribute_changes so we will re-render the Strong part when the attributes change.
For those who’re utilizing this in manufacturing, it is best to in all probability use a package deal Strong offers known as Solid Element solid-element Webcomponents wrapper for Solid. Latest version: 1.8.0, last published: a month ago. Start using solid-element in your project by running `npm i solid-element`. There are 59 other projects in the npm registry using solid-element. www.npmjs.com/package/solid-element that handles all this for you.

Again in our React app, we will now use our TodoLayout part:


export default perform TodoApp() {
  return (
    <todo-layout>
      <h1 slot="title">Todos</h1>
    </todo-layout>
  );
}

Word that we don’t have to import something from TodoLayout.jsx — we simply use the customized factor tag that we outlined.

Test it out:

That’s a React part rendering a Strong part, which takes a nested React factor as a toddler.

Including Todos

For the todo enter, we’ll peel the onion again a bit additional and write it with no framework in any respect!


customElements.outline("todo-input", TodoInput);

class TodoInput extends HTMLElement {
  constructor() {
    tremendous();
    this.shadow = this.attachShadow({ mode: "open" });
  }

  connectedCallback() {
    this.shadow.innerHTML = `
      <kind>
        <enter title="textual content" kind="textual content" placeholder="What must be carried out?" />
      </kind>
    `;

    this.shadow.querySelector("kind").addEventListener("submit", evt => {
      evt.preventDefault();
      const knowledge = new FormData(evt.goal);

      this.dispatchEvent(new CustomEvent("add", { element: knowledge.get("textual content") }));
      evt.goal.reset();
    });
  }
}

Between this, the instance net part and our Strong structure, you’re in all probability noticing a sample: connect a shadow root after which render some HTML inside it.
Whether or not we hand-write the HTML or use a framework to generate it, the method is roughly the identical.

Right here, we’re utilizing a custom event CustomEvent – Web APIs | MDN The CustomEvent interface represents events initialized by an application for any purpose. developer.mozilla.org/en-US/docs/Web/API/CustomEvent to speak with the dad or mum part.
When the shape is submitted, we dispatch an add occasion with the enter textual content.

Occasion queues are sometimes used to decouple communication Event Queue · Decoupling Patterns · Game Programming Patterns gameprogrammingpatterns.com/event-queue.html between parts of a software program system.
Browsers lean closely on occasions, and customized occasions particularly are an essential device within the net parts toolbox — particularly so as a result of the customized factor acts as a pure occasion bus that may be accessed from outdoors the net part.

Earlier than we will proceed including parts, we have to determine the right way to deal with our state.
For now, we’ll simply maintain it in our React TodoApp part.
Though we’ll finally outgrow useState, it’s an ideal place to start out.

Every todo can have three properties: an id, a textual content string describing it, and a carried out boolean indicating whether or not it’s been accomplished.


import { useCallback, useState } from "react";

let id = 0;
export default perform TodoApp() {
  const [todos, setTodos] = useState([]);

  export perform addTodo(textual content) {
    setTodos(todos => [...todos, { id: id++, text, done: false }]);
  }

  const inputRef = useCallback(ref => {
    if (!ref) return;
    ref.addEventListener("add", evt => addTodo(evt.element));
  }, []);

  return (
    <todo-layout>
      <h1 slot="title">Todos</h1>
      <todo-input slot="enter" ref={inputRef}></todo-input>
    </todo-layout>
  );
}

We’ll maintain an array of our todos in React state.
Once we add a todo, we’ll add it to the array.

The one awkward a part of that is that inputRef perform.
Our <todo-input> emits a customized add occasion when the shape is submitted.
Often with React, we’d connect occasion listeners utilizing props like onClick — however that solely works for occasions that React already is aware of about.
We have to hear for add occasions instantly.³

In React Land, we use refs Manipulating the DOM with Refs – React The library for web and native user interfaces react.dev/learn/manipulating-the-dom-with-refs to instantly work together with the DOM.
We mostly use them with the useRef hook, however that’s not the one approach!
The ref prop is definitely only a perform that will get known as with a DOM node.
Moderately than passing a ref returned from the useRef hook to that prop, we will as an alternative cross a perform that attaches the occasion listener to the DOM node instantly.

You is likely to be questioning why we’ve to wrap the perform in useCallback.
The reply lies within the legacy React docs on refs Refs and the DOM – React A JavaScript library for building user interfaces legacy.reactjs.org/docs/refs-and-the-dom.html#caveats-with-callback-refs (and, so far as I can inform, has not been introduced over to the brand new docs):

If the ref callback is outlined as an inline perform, it’s going to get known as twice throughout updates, first with null after which once more with the DOM factor. It is because a brand new occasion of the perform is created with every render, so React must clear the outdated ref and arrange the brand new one. You possibly can keep away from this by defining the ref callback as a certain methodology on the category, however word that it shouldn’t matter usually.

On this case, it does matter, since we don’t need to connect the occasion listener once more on each render.
So we wrap it in useCallback to make sure that we cross the identical occasion of the perform each time.

Todo Objects

To this point, we will add todos, however not see them.
The subsequent step is writing a part to point out every todo merchandise.
We’ll write that part with Svelte Svelte • Cybernetically enhanced web apps svelte.dev .

Svelte helps customized components out of the box Custom elements API • Docs • Svelte svelte.dev/docs/custom-elements-api .
Moderately than persevering with to point out the identical net part wrapper boilerplate each time, we’ll simply use that characteristic!

Right here’s the code:


<svelte:choices customElement="todo-item" />

<script>
  import { createEventDispatcher } from "svelte";

  export let id;
  export let textual content;
  export let carried out;

  const dispatch = createEventDispatcher();
  $: dispatch("test", { id, carried out });
</script>

<div>
   <enter id="todo-{id}" kind="checkbox" bind:checked={carried out} />
  <label for="todo-{id}">{textual content}</label>
  <button aria-label="delete {textual content}" on:click on={() => dispatch("delete", { id })}>
    <svg xmlns="http://www.w3.org/2000/svg" width="12" peak="12" viewBox="0 0 12 12">
      <path
        d="M10.707,1.293a1,1,0,0,0-1.414,0L6,4.586,2.707,1.293A1,1,0,0,0,1.293,2.707L4.586,6,1.293,9.293a1,1,0,1,0,1.414,1.414L6,7.414l3.293,3.293a1,1,0,0,0,1.414-1.414L7.414,6l3.293-3.293A1,1,0,0,0,10.707,1.293Z"
        fill="currentColor"
      />
    </svg>
  </button>
</div>

With Svelte, the <script> tag isn’t actually rendered to the DOM — as an alternative, that code runs when the part is instantiated.
Our Svelte part takes three props: id, textual content and carried out.
It additionally creates a customized occasion dispatcher, which might dispatch occasions on the customized factor.

The $: syntax declares a reactive block.
It signifies that each time the values of id or carried out change, it’s going to dispatch a test occasion with the brand new values.
id in all probability received’t change, so what this implies in observe is that it’ll dispatch a test occasion each time we test or uncheck the todo.

Again in our React part, we loop over our todos and use our new <todo-item> part.
We additionally want a pair extra utility capabilities to take away and test todos, and one other ref callback to connect the occasion listeners to every <todo-item>.

Right here’s the code:


import { useCallback, useState } from "react";

let id = 0;
export default perform TodoApp() {
  const [todos, setTodos] = useState([]);

  export perform addTodo(textual content) {
    setTodos(todos => [...todos, { id: id++, text, done: false }]);
  }

  export perform removeTodo(id) {
    setTodos(todos => todos.filter(todo => todo.id !== id));
  }

  export perform checkTodo(id, carried out) {
    setTodos(todos => todos.map(todo => (todo.id === id ? { ...todo, carried out } : todo)));
  }

  const inputRef = useCallback(ref => {
    if (!ref) return;
    ref.addEventListener("add", evt => addTodo(evt.element));
  }, []);

  const todoRef = useCallback(ref => {
    if (!ref) return;
    ref.addEventListener("test", evt => checkTodo(evt.element.id, evt.element.carried out));
    ref.addEventListener("delete", evt => removeTodo(evt.element.id));
  }, []);

  return (
    <todo-layout>
      <h1 slot="title">Todos</h1>
      <ul>
        {todos.map(todo => (
          <li key={todo.id}>
            <todo-item ref={todoRef} {...todo} />
          </li>
        ))}
      </ul>
      <todo-input slot="enter" ref={inputRef}></todo-input>
    </todo-layout>
  );
}

Now the checklist truly exhibits all our todos! And after we add a brand new todo, it exhibits up within the checklist!

Filtering Todos

The final characteristic so as to add is the flexibility to filter todos.

Earlier than we will add that, although, we have to do a little bit of refactoring.

I need to present one other approach that net parts can talk with one another: utilizing a shared retailer.
Most of the frameworks we’re utilizing have their very own retailer implementations, however we’d like a retailer that we will use with all of them.
For that cause, we’ll use a library known as Nano Stores GitHub – nanostores/nanostores: A tiny (298 bytes) state manager for React/RN/Preact/Vue/Svelte with many atomic tree-shakable stores A tiny (298 bytes) state manager for React/RN/Preact/Vue/Svelte with many atomic tree-shakable stores – GitHub – nanostores/nanostores: A tiny (298 bytes) state manager for React/RN/Preact/Vue/Svel… github.com/nanostores/nanostores .

First, we’ll make a brand new file known as retailer.js with our todo state rewritten utilizing Nano Shops:


import { atom, computed } from "nanostores";

let id = 0;
export const $todos = atom([]);
export const $carried out = computed($todos, todos => todos.filter(todo => todo.carried out));
export const $left = computed($todos, todos => todos.filter(todo => !todo.carried out));

export perform addTodo(textual content) {
  $todos.set([...$todos.get(), { id: id++, text }]);
}

export perform checkTodo(id, carried out) {
  $todos.set($todos.get().map(todo => (todo.id === id ? { ...todo, carried out } : todo)));
}

export perform removeTodo(id) {
  $todos.set($todos.get().filter(todo => todo.id !== id));
}

export const $filter = atom("all");

The core logic is similar; a lot of the adjustments are simply porting from the useState API to the Nano Shops API.
We did add two new computed stores GitHub – nanostores/nanostores: A tiny (298 bytes) state manager for React/RN/Preact/Vue/Svelte with many atomic tree-shakable stores A tiny (298 bytes) state manager for React/RN/Preact/Vue/Svelte with many atomic tree-shakable stores – GitHub – nanostores/nanostores: A tiny (298 bytes) state manager for React/RN/Preact/Vue/Svel… github.com/nanostores/nanostores#computed-stores , $carried out and $left, that are “derived” from the $todos retailer and return accomplished and incomplete todos, respectively.
We additionally added a brand new retailer, $filter, which can maintain the present filter worth.

We’ll write our filter part with Vue Vue.js – The Progressive JavaScript Framework | Vue.js Vue.js – The Progressive JavaScript Framework vuejs.org .


<script setup>
  import { useStore, useVModel } from "@nanostores/vue";

  import { $todos, $carried out, $left, $filter } from "./retailer.js";

  const filter = useVModel($filter);
  const todos = useStore($todos);
  const carried out = useStore($carried out);
  const left = useStore($left);
</script>

<template>
  <div>
    <label>
      <enter kind="radio" title="filter" worth="all" v-model="filter" />
      <span> All ({{ todos.size }})</span>
    </label>
    <label>
      <enter kind="radio" title="filter" worth="todo" v-model="filter" />
      <span> Todo ({{ left.size }})</span>
    </label>

    <label>
      <enter kind="radio" title="filter" worth="carried out" v-model="filter" />
      <span> Executed ({{ carried out.size }})</span>
    </label>
  </div>
</template>

The syntax is fairly much like Svelte’s: the <script> tag on the high is run when the part is instantiated, and the <template> tag accommodates the part’s markup.

Vue doesn’t make compiling a part to a customized factor fairly so simple as Svelte does. We have to create one other file, import the Vue part and name defineCustomElement Vue and Web Components | Vue.js Vue.js – The Progressive JavaScript Framework vuejs.org/guide/extras/web-components.html on it:


import { defineCustomElement } from "vue";

import TodoFilters from "./TodoFilters.ce.vue";

customElements.outline("todo-filters", defineCustomElement(TodoFilters));

Again in React Land, we’ll refactor our part to make use of Nano Shops slightly than useState, and convey within the <todo-filters> part:


import { useStore } from "@nanostores/react";
import { useCallback } from "react";

import { $todos, $carried out, $left, $filter, addTodo, removeTodo, checkTodo } from "./retailer.js";

export default perform App() {
  const filter = useStore($filter);
  const todos = useStore($todos);
  const carried out = useStore($carried out);
  const left = useStore($left);
  const seen = filter === "todo" ? left : filter === "carried out" ? carried out : todos;

  const todoRef = useCallback(ref => {
    if (!ref) return;
    ref.addEventListener("test", evt => checkTodo(evt.element.id, evt.element.carried out));
    ref.addEventListener("delete", evt => removeTodo(evt.element.id));
  }, []);

  const inputRef = useCallback(ref => {
    if (ref) ref.addEventListener("add", evt => addTodo(evt.element));
  }, []);

  return (
    <todo-layout>
      <h1 slot="title">Todos</h1>
      <todo-filters slot="filters" />

      <div slot="todos">
        {seen.map(todo => (
          <todo-item key={todo.id} ref={todoRef} {...todo} />
        ))}
      </div>
      <todo-input ref={inputRef} slot="enter" />
    </todo-layout>
  );
}

We did it!
We now have a completely useful todo app, written with 4 completely different frameworks — React, Strong, Svelte and Vue — plus a part written in vanilla JavaScript.

Transferring Ahead

The purpose of this text is to not persuade you that it is a good approach to write net apps.
It’s to point out that there are methods to construct an online app apart from writing your complete factor with a single JavaScript framework — and moreover, that net parts truly make it considerably simpler to try this.

You possibly can progressively improve static HTML.
You possibly can construct wealthy interactive JavaScript “islands” that naturally talk with hypermedia libraries like HTMX </> htmx – high power tools for html htmx.org .
You possibly can even wrap an online part round a framework part, and use it with any different framework.

Net parts drastically loosen the coupling of JavaScript frameworks by offering a typical interface that all frameworks can use.
From a shopper’s viewpoint, net parts are simply HTML tags — it doesn’t matter what goes on “underneath the hood”.

If you wish to mess around with this your self, I’ve made a CodeSandbox with our example todo app codesandbox.io/p/devbox/polyglot-todos-wm4lwn .