DEV Community: Joan Llenas Masó

Web components: composition techniques

Joan Llenas Masó — Wed, 30 Nov 2022 00:31:50 +0000

The web Components v1 specification consists of three main technologies that can be used to create reusable custom elements:

Custom elements
HTML templates
Shadow DOM

Web components usually work as atomic units that don't need anything from the outside world. Sometimes, though, they require a certain degree of versatility, only reachable with the help of composition.

In this article, we will see one such scenario by creating a minimal dropdown implementation.

We will leverage what we've done in the previous articles of this series by reusing a lot of code.

Dropdown structure
Composing a dropdown
The project
The index.html file
The main.js module
The style.css file
The my-button web component
- ::slotted
The my-dropdown web component
- part and exportparts
- ::part
The my-dropdown-option web component
Recap

Dropdown structure

A basic dropdown is made of three main parts:

A button that toggles the dropdown options.
A popover that holds the options.
A collection of selectable options.

source

Composing a dropdown

By bringing that structure into web component land, we could envision a user API such as:

<my-dropdown placeholder="Select">
  <my-dropdown-option value="option-1">
    Option 1
    <p slot="content" class="option-description">
      Option 1 description
    </p>
  </my-dropdown-option>
  (...)
</my-dropdown>

It's similar to the <select> control but a little more interesting because the options can contain more stuff. And it will look like this:

The project

The code will be all vanilla Js using native modules.
No tooling/bundling is required, just The Web Platform™️.

.
├── package.json
└── src
    ├── components
    │   ├── my-button
    │   │   ├── my-button.css
    │   │   └── my-button.js
    │   ├── my-dropdown
    │   │   ├── my-dropdown.css
    │   │   └── my-dropdown.js
    │   └── my-dropdown-option
    │       ├── my-dropdown-option.css
    │       └── my-dropdown-option.js
    ├── index.html
    ├── main.js
    └── style.css

The `index.html` file

It makes sense to start with the entry point of our example to see everything that's being loaded.

<!-- index.html -->
<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <script type="module" src="/main.js"></script>
    <link rel="stylesheet" href="/style.css" />
  </head>

  <body>
    <my-dropdown placeholder="Select">
      <my-dropdown-option value="light">
        Light theme
        <p slot="content" class="option-description">
          Your vision sharpens, enabling you to focus better
        </p>
      </my-dropdown-option>
      <my-dropdown-option value="dark">
        Dark theme
        <p slot="content" class="option-description">
          Reduce eye strain in low light conditions
        </p>
      </my-dropdown-option>
      <my-dropdown-option value="sepia">
        Sepia theme
        <p slot="content" class="option-description">Middle ground</p>
      </my-dropdown-option>
    </my-dropdown>
  </body>
</html>

A couple of remarks.

We initialise all web components by loading the main.js module and add some logic to toggle the page theme between light, dark and sepia.

<script type="module" src="/main.js"></script>

The style.css file contains CSS variables that define the aforementioned supported themes and a few custom styles that use fancy selectors that are worth exploring.

<link rel="stylesheet" href="/style.css" />

The `main.js` module

As we mentioned earlier, this is a native Javascript module, that's why we can use the import syntax.

Here we're loading our web components and adding some logic to toggle the page theme.

// main.js
import "/components/my-button/my-button.js";
import "/components/my-dropdown/my-dropdown.js";
import "/components/my-dropdown-option/my-dropdown-option.js";

const main = () => {
  const myDropdown = document.querySelector("my-dropdown");
  myDropdown.addEventListener("myDropdownChange", (event) => {
    console.log(event.type, event.detail);
    document.querySelector("html").dataset.theme = event.detail;
  });
};
window.addEventListener("DOMContentLoaded", main);

By setting <html data-theme="dark"> and with the help of CSS variables, we can manipulate the look and feel of the entire page!

The `style.css` file

This file contains mainly CSS variables, but some interesting selectors are worth exploring too. We'll examine them when we get to the components.

/* style.css */
:root {
  --background-color: #fff;

  --color-brand: #0b66fa;
  --color-white: #fff;
  --color-black: #000000de;

  --border-radius-sm: 8px;
  --gap-sm: 8px;
  --font-sm: 18px;
  --font-md: 20px;

  /* theme */
  --background-low-contrast: var(--color-white);
  --background-high-contrast: var(--color-black);

  --text-low-contrast: var(--color-white);
  --text-high-contrast: var(--color-black);

  --border-low-contrast: 1px solid var(--color-white);
  --border-high-contrast: 1px solid var(--color-black);
}

html[data-theme="dark"] {
  --background-color: #212a2e;

  --background-low-contrast: var(--color-black);
  --background-high-contrast: var(--color-white);

  --text-low-contrast: var(--color-black);
  --text-high-contrast: var(--color-white);

  --border-low-contrast: 1px solid var(--color-black);
  --border-high-contrast: 1px solid var(--color-white);
}

html[data-theme="sepia"] {
  --background-color: #bfa26b;

  --background-low-contrast: #bfa26b;
  --background-high-contrast: #594225;

  --text-low-contrast: #bfa26b;
  --text-high-contrast: #401902;

  --border-low-contrast: 1px solid #bfa26b;
  --border-high-contrast: 1px solid #401902;
}

body {
  background-color: var(--background-color);
  font-family: sans-serif;
}

/* 
 Styling user content placed inside of a slot
*/
my-dropdown-option .option-description {
  font-size: small;
  color: var(--text-high-contrast);
}

my-dropdown-option:hover .option-description {
  color: var(--text-low-contrast);
}

/* 
----------------------------
-------- CSS PARTS ---------
-- styling the shadow DOM --
----- from the outside -----
----------------------------
*/

my-dropdown::part(options) {
  border-radius: var(--border-radius-sm);
}

my-dropdown-option:not(:first-child)::part(container) {
  border-top: var(--border-high-contrast);
}

my-dropdown-option:first-child::part(container) {
  border-top-left-radius: var(--border-radius-sm);
  border-top-right-radius: var(--border-radius-sm);
}

my-dropdown-option:last-child::part(container) {
  border-bottom-left-radius: var(--border-radius-sm);
  border-bottom-right-radius: var(--border-radius-sm);
}

The `<my-button>` web component

The my-button.js code is the same we had on previous articles of this series, but with an icon slot, the HTML template inlined, and the CSS loaded from an external file.

// components/my-button/my-button.js
const template = document.createElement("template");
template.innerHTML = /* html */ `
  <style>
    @import "/components/my-button/my-button.css";
  </style>
  <button>
    <slot></slot>
    <slot name="icon"></slot>
  </button>
`;

customElements.define(
  "my-button",
  class extends HTMLElement {
    static get observedAttributes() {
      return ["variant"];
    }

    constructor() {
      super();
      const shadowRoot = this.attachShadow({ mode: "open" });
      shadowRoot.appendChild(template.content.cloneNode(true));
    }
  }
);

Loading CSS externally is an excellent way to improve the DX and make the implementation more self-contained.

Worth mentioning that the /* html */ comment right before the HTML template tells VScode (es6-string-html extension required) that this block has to be syntax highlighted.

Cool, huh? 😎

Regarding CSS, the only thing that differs from the my-button implementation in the previous article is the introduction of the icon slot, which we select with the ::slotted selector.

/* components/my-button/my-button.css */
:host {
  display: inline;
}

:host button {
  cursor: pointer;
  font-size: 20px;
  font-weight: 700;
  padding: 12px;
  min-width: 180px;
  border-radius: 12px;
}

:host([variant="primary"]) button {
  background-color: var(--color-brand);
  color: var(--color-white);
  border: 0;
}

:host([variant="secondary"]) button {
  border: var(--border-high-contrast);
  background-color: var(--background-low-contrast);
  color: var(--text-high-contrast);
}

slot[name="icon"]::slotted(*) {
  margin-left: var(--gap-sm);
}

`::slotted`

::slotted only works from within the component. You can't use ::slotted from, let's say, the style.css file. Only styles local to the shadow DOM have access to this selector. Also, it only targets elements, not text nodes.

Here we are saying: Select any element inside the slot named icon:

slot[name="icon"]::slotted(*) { /* ... */ }

The `<my-dropdown>` web component

// components/my-dropdown/my-dropdown.js
const template = document.createElement("template");
template.innerHTML = /* html */ `
  <style>
    @import "/components/my-dropdown/my-dropdown.css";
  </style>
  <my-button variant="secondary"></my-button>
  <div part="options">
    <slot></slot>
  </div>
`;

customElements.define(
  "my-dropdown",
  class extends HTMLElement {
    static get observedAttributes() {
      return ["placeholder", "open"];
    }

    get placeholder() {
      return this.getAttribute("placeholder") || "";
    }

    get open() {
      return this.hasAttribute("open") && this.getAttribute("open") !== "false";
    }

    set open(value) {
      value === true
        ? this.setAttribute("open", "")
        : this.removeAttribute("open");
    }

    constructor() {
      super();
      this.toggle = this.toggle.bind(this);
      this.optionClickHandler = this.optionClickHandler.bind(this);
      const shadowRoot = this.attachShadow({ mode: "open" });
      shadowRoot.host.setAttribute("exportparts", "options");
      shadowRoot.appendChild(template.content.cloneNode(true));
    }

    attributeChangedCallback() {
      this.render();
    }

    connectedCallback() {
      this.shadowRoot
        .querySelector("my-button")
        .addEventListener("click", this.toggle);
      this.addEventListener("myDropdownOptionClick", this.optionClickHandler);
    }

    optionClickHandler(event) {
      event.stopImmediatePropagation();
      this.selection = event.detail.label;
      this.open = false;
      this.dispatchEvent(
        new CustomEvent("myDropdownChange", {
          detail: event.detail.value,
        })
      );
      this.render();
    }

    toggle() {
      this.open = !this.open;
      this.render();
    }

    render() {
      this.shadowRoot.querySelector("my-button").innerHTML = /* html */ `
        ${this.selection || this.placeholder}
        <span slot="icon">${this.open ? "▲" : "▼"}</span>
      `;
    }
  }
);

As expected, this file has some more logic to digest. Let's take a look at the interesting bits.

The `part` and `exportparts` attributes

In the same way that ::slotted is used to select elements local to the same template, the part attribute (and the accompanying exportparts) is used to enable selecting elements from outside of the template. Or, wording it differently, it effectively exposes a CSS API that end users can consume from the global CSS scope! 🤯

In the context of our dropdown, the CSS API is created by these two lines of code:

<div part="options">

and

shadowRoot.host.setAttribute("exportparts", "options");

::part()

To better understand how this works, we can return to the global CSS located in our style.css file, where we make use of the options part:

/* style.css (around line 75)  */
my-dropdown::part(options) {
  border-radius: var(--border-radius-sm);
}

As we can see here, the host component can also use the ::part() pseudo selector.

/* components/my-dropdown/my-dropdown.css */
:host {
  display: block;
}

:host::part(options) {
  display: none;
  flex-direction: column;
  margin-top: var(--gap-sm);
  border: var(--border-high-contrast);
}

:host([open])::part(options) {
  display: flex;
}

We used the ::part() pseudo selector to style the component instead of creating a class selector.

:host::part(options) {}: Select the options part.
:host([open])::part(options) {}: Select the options part only when the host component has the open attribute set.

The `<my-dropdown-option>` web component

And, last but not least, the options web component.

// components/my-dropdown-option/my-dropdown-option.js
const template = document.createElement("template");
template.innerHTML = /* html */ `
  <style>
    @import "/components/my-dropdown-option/my-dropdown-option.css";
  </style>
  <div part="container">
    <slot></slot>
    <slot name="content"></slot>
  </div>
`;

customElements.define(
  "my-dropdown-option",
  class extends HTMLElement {
    static get observedAttributes() {
      return ["value"];
    }

    get value() {
      return this.getAttribute("value");
    }

    get label() {
      const slot = this.shadowRoot.querySelectorAll("slot")[0];
      return slot.assignedNodes().at(0).textContent;
    }

    constructor() {
      super();
      this.clickHandler = this.clickHandler.bind(this);
      const shadowRoot = this.attachShadow({ mode: "open" });
      shadowRoot.host.setAttribute("exportparts", "container");
      shadowRoot.appendChild(template.content.cloneNode(true));
    }

    connectedCallback() {
      this.addEventListener("click", this.clickHandler);
    }

    clickHandler() {
      this.dispatchEvent(
        new CustomEvent("myDropdownOptionClick", {
          detail: {
            label: this.label,
            value: this.value,
          },
          bubbles: true,
          cancelable: true,
          composed: true,
        })
      );
    }
  }
);

A couple of remarks here.

The dispatched event uses a CustomEvent instance with composed set to true, which is very important to allow the event to propagate across the shadow DOM boundary into the standard DOM.

We can also take a glimpse at what the Slot API looks like.

get label() {
  const slot = this.shadowRoot.querySelectorAll("slot")[0];
  return slot.assignedNodes().at(0).textContent;
}

Not a fan, to be honest, but it's what it is!

Now, let's look at the my-dropdown-option component CSS:

/* components/my-dropdown-option/my-dropdown-option.css */
:host {
  display: block;
}

:host::part(container) {
  padding: 8px 16px;
  background-color: var(--background-low-contrast);
  color: var(--text-high-contrast);
  font-size: var(--font-sm);
}

:host::part(container):hover {
  background-color: var(--background-high-contrast);
  color: var(--text-low-contrast);
}

That was nothing we haven't already covered, but two things are worth mentioning. Let's return to the global style.css file for a moment.

/* style.css (around line 79) */
my-dropdown-option:not(:first-child)::part(container) {
  border-top: var(--border-high-contrast);
}

my-dropdown-option:first-child::part(container) {
  border-top-left-radius: var(--border-radius-sm);
  border-top-right-radius: var(--border-radius-sm);
}

my-dropdown-option:last-child::part(container) {
  border-bottom-left-radius: var(--border-radius-sm);
  border-bottom-right-radius: var(--border-radius-sm);
}

We can see how the end user used the exported parts to tweak the option's default look and feel, round the popover borders, and add separators between options.

Recap

Unless I forgot to mention some obscure API, I'd say that we've covered the whole v1 spec by implementing the dropdown component.

Project code

Github repo with the full project source code.

Related things worth exploring

lit.dev Web components library.
stenciljs.com Web components compiler.
storybook.js.org Frontend workshop for building UI components in isolation.

A few links

Web components: styles piercing shadow DOM

Joan Llenas Masó — Wed, 30 Nov 2022 00:31:30 +0000

The web Components v1 specification consists of three main technologies that can be used to create reusable custom elements:

Custom elements
HTML templates
Shadow DOM

:host

In addition to these technologies, CSS has also been updated to support web components. For instance, the new :host pseudo selector has been added to select the web component from inside itself.
This pseudo selector can also be combined like you would in other scenarios.

/* <my-button> styles block */

:host{} /* selects the my-button tag */
:host(.primary){} /* selects the my-button when it has the primary class */
:host([variant="primary"]){} /* selects the my-button when the `primary` variant is set */

We'll see this in action in the following example.

Theming with CSS variables

There are different ways to pierce the shadow DOM when it comes to styling, the main one being CSS variables.
Quick example:

/* global-styles.css */
:root {
  --brand-color: blue;
}

<!-- our web component template-->
<template>
  <style>
    button {
      background-color: var(--brand-color);
    }
  </style>
  ...
</template>

Here, the template's button background will get the --brand-color defined in :root. In a nutshell, that's the primary mechanism for theming web components.

Theming the `<my-button>` component

/* styles.css */
:root {
  --background-color: #fff;

  --color-brand: #0b66fa;
  --color-white: #fff;
  --color-black: #000000de;

  --background-low-contrast: var(--color-white);
  --background-high-contrast: var(--color-black);

  --text-low-contrast: var(--color-white);
  --text-high-contrast: var(--color-black);

  --border-low-contrast: 1px solid var(--color-white);
  --border-high-contrast: 1px solid var(--color-black);
}

html[data-theme='dark'] {
  --background-color: #212a2e;

  --background-low-contrast: var(--color-black);
  --background-high-contrast: var(--color-white);

  --text-low-contrast: var(--color-black);
  --text-high-contrast: var(--color-white);

  --border-low-contrast: 1px solid var(--color-black);
  --border-high-contrast: 1px solid var(--color-white);
}

body {
  background-color: var(--background-color);
}

<!-- index.html -->
<!DOCTYPE html>
<html>
  <head>
    <link rel="stylesheet" href="styles.css" />
    <script src="my-button.js"></script>
    <script>
      function toggleTheme() {
        if (document.querySelector('html').dataset.theme === 'dark') {
          document.querySelector('html').dataset.theme = '';
        } else {
          document.querySelector('html').dataset.theme = 'dark';
        }
      }
    </script>
  </head>

  <body>
    <template id="my-button-template">
      <style>
        button {
          cursor: pointer;
          font-size: 20px;
          font-weight: 700;
          padding: 12px;
          min-width: 180px;
          border-radius: 12px;
        }
        :host([variant='primary']) button {
          background-color: var(--color-brand);
          color: var(--color-white);
          border: 0;
        }
        :host([variant='secondary']) button {
          border: var(--border-high-contrast);
          background-color: var(--background-low-contrast);
          color: var(--text-high-contrast);
        }
      </style>
      <button><slot></slot></button>
    </template>

    <my-button variant="primary" onclick="toggleTheme()"
      >Toggle theme</my-button
    >
    <my-button variant="secondary">Secondary</my-button>
    <button class="primary">Plain HTML &lt;button&gt;</button>
  </body>
</html>

// my-button.js
class MyWebComponent extends HTMLElement {
  constructor() {
    super();
    const template = document.getElementById('my-button-template').content;
    const shadowRoot = this.attachShadow({ mode: 'open' });
    shadowRoot.appendChild(template.cloneNode(true));
  }
}

customElements.define('my-button', MyWebComponent);

By clicking the Toggle theme button, you will see how the overall look and feel changes from light to dark and vice versa.

A couple of interesting facts about this example:

We've eliminated all style-handling logic from the component and moved it to the CSS declaration. In particular:

This Js code:

const variant = this.getAttribute('variant') || '';
this.shadowRoot.querySelector('button').className = variant;

Was replaced by this CSS:

:host([variant='primary']) button { ... }
:host([variant='secondary']) button { ... }

So we could remove all life cycle callbacks and the render() function.

Activating the dark theme is as easy as adding data-theme="dark" to the main <html> tag.

<html data-theme="dark">...</html>

The magic happens by pure CSS matching :)

Coming up next

The following article will show how web components compose by building a dropdown.

Web components: templates and shadow DOM

Joan Llenas Masó — Wed, 30 Nov 2022 00:31:02 +0000

The web Components v1 specification consists of three main technologies that can be used to create reusable custom elements:

Custom elements
HTML templates
Shadow DOM

HTML templates

The concept of HTML templates is relatively straightforward. With the <template> tag, you create a portion of DOM content that is parsed only once. This element is not rendered in the DOM until cloned, which can be done as often as needed.

<template id="my-button-template">
  <button>hola</button>
</template>

const template = document.getElementById("my-button-template");
document.body.appendChild(template.content);

Content projection with `<slot>`

Another cool thing about the <template> tag is that you can define specific areas (the slots) for projecting the content from outside the template.

For instance, to make the previous example more useful, we could expose the button label to the outside world by adding a slot tag instead of the hardcoded value.

<template id="my-button-template">
  <button><slot></slot></button>
</template>

This is only useful in custom elements, as we will see shortly.

Shadow DOM

The Shadow DOM is an API that gives us access to arguably the most important aspect of web components: component isolation.

The shadow DOM enables a few characteristics of the web components spec, which, I would say, drives a significant part of the remaining spec.

Enabling shadow DOM support in our component is a one-liner:

class MyWebComponent extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({ mode: 'open' }); // shadow DOM enabled!
    this.shadowRoot.innerHTML = '<p>hola</p>';
  }
}

The attachShadow() method creates the shadow DOM, and the shadowRoot property references the root of that shadow DOM tree.

As stated previously, an interesting effect of enabling the shadow DOM is that the DOM subtree is effectively hidden from the rest of the page.
Let's see an example.

<!-- index.html -->
<!DOCTYPE html>
<html lang="en">
  <head>
    <script type="module" src="my-button.js"></script>
    <style>
      button {
        color: red;
      }
    </style>
  </head>
  <body>
    <my-button>my-button</my-button>
    <button>Plain HTML button</button>
  </body>
</html>

// my-button.js
customElements.define(
  'my-button',
  class extends HTMLElement {
    constructor() {
      super();
      this.attachShadow({ mode: 'open' });
      this.shadowRoot.innerHTML = '<button><slot></slot></button>';
    }
  }
);

We can see that our component's button is not being affected by the global button styles.

Putting it all together

Following the <my-button> example of the previous article in the series, let's extract its markup to a <template> and add shadow DOM support.

<!-- index.html -->
<!DOCTYPE html>
<html>
  <head>
    <script src="my-button.js"></script>
  </head>

  <body>
    <template id="my-button-template">
      <style>
      button {
        cursor: pointer;
        font-size: 20px;
        font-weight: 700;
        padding: 12px;
        min-width: 180px;
        border-radius: 12px;
      }
      button.primary {
        background-color: #0b66fa;
        color: #fff;
        border: 0;
      }
      button.secondary {
        border: 1px solid rgba(0, 0, 0, 0.12);
        background-color: #fff;
        color: #000000de;
      }
      </style>
      <button><slot></slot></button>
    </template>

    <my-button>Default</my-button>
    <my-button variant="primary">Primary</my-button>
    <my-button variant="secondary">Secondary</my-button>
    <button class="primary">Plain HTML &lt;button&gt;</button>
  </body>
</html>

class MyWebComponent extends HTMLElement {
  static get observedAttributes() {
    return ['variant'];
  }

  constructor() {
    super();
    const template = document.getElementById('my-button-template').content;
    const shadowRoot = this.attachShadow({ mode: 'open' });
    shadowRoot.appendChild(template.cloneNode(true));
  }

  connectedCallback() {
    this.render();
  }

  attributeChangedCallback(name, oldValue, newValue) {
    this.render();
  }

  render() {
    const variant = this.getAttribute('variant') || '';
    this.shadowRoot.querySelector('button').className = variant;
  }
}

customElements.define('my-button', MyWebComponent);

As we can see here, the plain HTML button is not affected by the styles in the template because they are local to the <my-button>'s shadow DOM tree.

Nothing new related to web components, but it's worth mentioning how we use templates. We have to get the reference, clone it and append it to the shadow DOM root.

const template = document.getElementById('my-button-template').content;
const shadowRoot = this.attachShadow({ mode: 'open' });
shadowRoot.appendChild(template.cloneNode(true));

Coming up next

The following article will introduce CSS variables for theming our web components. Yes, it turns out that there are mechanisms to make styles pierce the shadow DOM!

Web components: custom elements

Joan Llenas Masó — Wed, 30 Nov 2022 00:30:38 +0000

The web Components v1 specification consists of three main technologies that can be used to create reusable custom elements:

Custom elements
HTML templates
Shadow DOM

Custom elements

Custom elements allow you to define new tags by declaring classes that extend the HTMLElement base class.

class MyButton extends HTMLElement {
  // (...)
}

The HTMLElement base class exposes callback functions you can use to do stuff at any point in the component lifecycle.

class MyButton extends HTMLElement {
  attributeChangedCallback(name, oldValue, newValue) {
    // (...)
  }
}

With custom elements, you define the component API by exposing attributes and events.

<my-button variant="primary">Click me</my-button>

Iteration 1: The simplest custom element

Let's create the simplest custom element ever so we understand the basics.

<!-- index.html -->
<!DOCTYPE html>
<html>
  <head>
    <script src="my-button.js"></script>
  </head>

  <body>
    <my-button></my-button>
  </body>
</html>

// my-button.js
class MyWebComponent extends HTMLElement {
  connectedCallback() {
    this.innerHTML = `<button>hola</button>`;
  }
}

customElements.define('my-button', MyWebComponent);

A couple of key parts in this example:

The MyWebComponent class uses the connectedCallback life cycle method to add the <button> markup. Note that we are using this.innerHTML = ..., that is because we are inside the HTMLElement! We have access to all DOM APIs, which will be scoped to the element.
The window.customElements gives you access to the custom elements registry, and the define() method registers the declared class with the provided tag name (which, by the way, must have a dash in its name to ensure there are no collisions with built-in HTML tags).

In this contrived example, we only focused on creating the custom element, which leaves a lot to be desired! Let's spice things up a bit!

Iteration 2: Declarative component API with attributes

Let's expose the button label as an attribute and allow setting the button look and feel based on the variant attribute value.

<!-- index.html -->
<!DOCTYPE html>
<html>
  <head>
    <script src="my-button.js"></script>
    <style>
      body {
        display: flex;
        flex-direction: column;
        gap: 8px;
      }
      button {
        cursor: pointer;
        font-size: 20px;
        font-weight: 700;
        padding: 12px;
        min-width: 180px;
        border-radius: 12px;
      }
      button.primary {
        background-color: #0b66fa;
        color: #fff;
        border: 0;
      }
      button.secondary {
        border: 1px solid rgba(0, 0, 0, 0.12);
        background-color: #fff;
        color: #000000de;
      }
    </style>
  </head>

  <body>
    <my-button label="Default"></my-button>
    <my-button variant="primary" label="Primary"></my-button>
    <my-button variant="secondary" label="Secondary"></my-button>
    <button class="primary">Plain HTML &lt;button&gt;</button>
  </body>
</html>

// my-button.js
class MyWebComponent extends HTMLElement {
  static get observedAttributes() {
    return ['variant', 'label'];
  }

  connectedCallback() {
    this.render();
  }

  attributeChangedCallback() {
    this.render();
  }

  render() {
    const label = this.getAttribute('label') || '';
    const variant = this.getAttribute('variant') || '';
    this.innerHTML = `
      <button class="${variant}">${label}</button>
    `;
  }
}

customElements.define('my-button', MyWebComponent);

A couple of interesting facts about this example:

If we want the component to be notified of changes to its properties via the attributeChangedCallback() method, we have to declare them using the observedAttributes() static method.
We've defined a few global CSS styles, and as we can see, all buttons are being styled, whether inside a custom element or not. That's not what we want for our web components. But fear not! Keep reading and find out how to solve this issue.

Coming up next

In the next article we'll isolate our component from the rest of the page while introducing the Shadow DOM, templates and slots.

DRY Typescript types

Joan Llenas Masó — Mon, 25 Jan 2021 16:12:32 +0000

Typescript gives us a few tools that we can use to reference existing types, which is very useful if we want to be consistent across our codebase.

Let's see a few examples:

Attention: contrived examples ahead.

Indexed type access

Say we have an interface like this one:

export interface User {
    username: string;
    age: number;
    fullName: {
        firstname: string;
        lastname: string;
    }
}

We can reference all those types inside User by using index syntax:

let userAge: User['age']; // number
let fullName: User['fullName']; // { firstname: string; lastname: string; }
let lastname: User['fullName']['lastname']; // string

This also works for function signatures, take a look at the fullName parameter:

function setFullName (user: User, fullName: User['fullName']): User {
    return {
        ...user,
        fullName
    };
};

Class methods can also be targetted with index syntax, the whole signature or just the return type, which is useful when some method uses a complex return type that doesn't reference any exported type:

class MyClass {
    myMethod() {
        return {
            foo: 'bar'
        }
    }
}

let myMethod: MyClass['myMethod'] // () => {foo: string;}
let myReturn: ReturnType<MyClass['myMethod']> // {foo: string;}

Indexed type access + instances

We can also apply the same techniques we've seen so far within the realm of instances thanks to the typeof operator:

const user = {
    username: 'picklerick',
    age: 70,
    fullName: {
        firstname: 'Rick',
        lastname: 'Sanchez'
    }
}

let fullName: typeof user['fullName'] // { firstname: string; lastname: string; }

Last but not least, typeof with class instances and function signatures:

class MyClass {
    prop = 'bar';
    method() {
        return {
            foo: this.prop
        }
    }
}
const myClass = new MyClass();
let myProp: typeof myClass['prop'] // string
let myMethod: typeof myClass['method'] // () => {foo: string;}
let myReturn: ReturnType<typeof myClass['method']> // {foo: string;}

Indexed type access + Generics

Generic types are inferred, so everything works the same:

interface Action<T> {
    type: string;
    payload: T;
}

interface User{
    id: string;
    name: string;
}

let addUserAction: Action<User>; // {type:string; payload: {id:string; name:string}}
let payload : typeof addUserAction['payload'] // User

Indexed type access + tuples

Tuples have similar syntax, but indexes are numbers instead of strings:

type MyTuple = [number, string];

let fst: MyTuple[0] // number
let snd: MyTuple[1] // string
let nope: MyTuple[3] // Error: Tuple type 'MyTuple' of length '2' has no element at index '3'.

We can also use the typeof operator here:

const myTupleValue: MyTuple = [3, 'hello'];
let fst: typeof myTupleValue[0] // number
let snd: typeof myTupleValue[1] // string

But we have to be explicit with the tuple type otherwise, what used to be a tuple becomes an array and the outcome is very different:

const myTupleValue = [5, 'hello'];
let fst: typeof myTupleValue[0] // string | number
let snd: typeof myTupleValue[1] // string | number
let yep: typeof myTupleValue[3] // string | number

Working with keys

Type keys are also accessible thanks to the keyof operator:

interface User {
    username: string;
    age: number;
}

let userKeys: keyof User // "username" | "age"

And, as you may have guessed, our friend typeof helps us with instances again:

const user = {
    username: 'picklerick',
    age: 70
}

let userKeys: keyof typeof user // "username" | "age"

Wrapping up

Creating new types with Typescript is super easy and cheap thanks to its structural typing nature, but that doesn't mean we should be careless about that. Having these techniques in our toolbelt can help us keep consistency across our codebase.

RemoteData, slaying a UI Antipattern with Angular

Joan Llenas Masó — Mon, 08 Jul 2019 10:48:22 +0000

Kris Jenkins How Elm slays a UI antipattern blog post about fixing a common UI state bug when fetching remote data has been around for a few years now, and its popularity has transcended the Elm ecosystem. A few blog posts explain how to achieve the same results with other languages/frameworks, but none of them is based on Angular2+.
In this article, I'll try to explain how to achieve something similar with Angular and TypeScript.

What we are trying to solve

You are making an API call, and you want to display different things based on the status of the request.

⠀

Taken from "How to fix a bad user interface", by Scott Hurff

The traditional approach

export interface CakeOfTheDay {
  isInProgress: boolean;
  error: string;
  data: {
    name: string;
    image: string;
    recipe: string;
  };
}

Let's see what each property means:

isInProgress: It's true while the remote data is being fetched.
error: It's either null (no errors) or any string (there are errors).
data: It's either null (no data) or an object (there is data).

There are a few problems with this approach but the main one is that it is possible to create invalid states such:

{
  isInProgress: true,
  error: 'Fatal error',
  data: {
    name: "Bacon cake",
    image: "cake.png",
    recipe: "Bacon, sugar, mix, stir, bake, enjoy!"
  }
}

How do we interpret this payload? Our Html template will have to use complex *ngIf statements to make sure that we are displaying what we should.

The RemoteData approach

The proposed solution uses an adaptation of Kris Jenkins' RemoteData library where instead of using a complex object, we use a single data type to express all possible request states:

export type RemoteData<T, E = string> =
  | NotAsked
  | InProgress<T>
  | Failure<E>
  | Success<T>;

This approach makes it impossible to create invalid states.
This pattern has served our team well for a long time, so, I decided to create the ngx-remotedata library. It works exceptionally well with ngrx!
With this library creating a robust UI stack will be as easy as throwing a few ngx-remotedata pipes and let the data do the rest:

<h4 *ngIf="remoteData | isNotAsked">No requests yet!</h4>
<h4 *ngIf="remoteData | isInProgress">In progress...</h4>
<h4 *ngIf="remoteData | isSuccess" style="color: green">
  {{ remoteData | successValue }}
</h4>
<h4 *ngIf="remoteData | isFailure" style="color: red">
  {{ remoteData | failureValue }}
</h4>

Library resources

Decoding JSON with Typescript

Joan Llenas Masó — Sun, 23 Dec 2018 17:41:54 +0000

Typescript is very well suited for adding type safety to a JavaScript program, but on its own, it's not enough to guarantee that it won't crash at run-time.

This article shows how JSON decoders can help to extend TypeScript compile-time guarantees to the run-time environment.

Runtime vs Compile time

The application you are working on deals with users, so you create a User type:

interface User {
   firstName: string;
   lastName: string;
   picture: string;
   email: string;
}

You'll use this type to annotate the /me API endpoint result, and then you'll do all sorts of things with this User but let's concentrate on the profile area of the app:

It'll display the concatenation of firstName + lastName.
Below the firstName + lastName you also want to display the email.
Finally, you want to show the picture of the user or, if not present, a default image.

What could go wrong? Well, for starters the User type is not telling the truth, It does not express all the permutations of User shapes that the API can return.
Let's see a few examples:

// The result has null properties
{ firstName: "John", lastName: null, picture: null, email: "john@example.com" }

// The API returned null
null

// The result has undefined properties
{ firstName: "John", lastName: "Doe", email: "john@example.com" }

// The API contract changed and the UI team wasn't notified
{ fName: "John", lName: "Doe", picture: 'pic.jpg', email: "john@example.com" }

You can cope with these issues by using defensive programming techniques, a.k.a. null / undefined checks behind if statements but, what happens when someone else wants to use the /me result elsewhere? Maybe your colleague trusts the User type, why not? What happens then? We introduced a new vector for runtime errors.

Enter Json decoders

You use Json decoders to make sure that a given run-time value complies with a specific compile-time type, and not only that but also gives you tools to apply transformations, failovers and more.

Json decoders have gained popularity lately thanks to Elm.
Elm's Json decoders are a core part of the language, and they are used all over the place to ensure a smooth JS to Elm communication.

The idea behind Json decoders is that you have a collection of basic decoders ( string, number, boolean, object, array... ) that you can compose into more complex decoders.

State-of-the-art JSON decoder libraries

There are a few JSON decoding libraries out there, but there's one that stood out from the rest when I made the research a while ago. Daniel Van Den Eijkel created something that kept the principles of the Elm decoding library while being idiomatic in TypeScript terms.

Unfortunately, the library was unmaintained and unpublished, so I decided to fork it, polish it, and release it as an npm package under the name ts.data.json.
My contribution to the library has been documentation, better error reporting, unit testing, API improvements, a few new decoders and publishing the npm package.

Using JSON decoders

Install the library:

npm install ts.data.json --save

Decoding basics

Before implementing our custom User decoder let's try decoding a string from start to finish.

import { JsonDecoder } from 'ts.data.json';

console.log( JsonDecoder.string.decode('Hi!') ); // Ok({value: 'Hi!'})

Finished! 🎉

Unwrapping decoder results

As we saw in our previous example the decoding process has two steps.

First, we declare the decoder with JsonDecoder.string.
Second, we execute the decoder passing a JavaScript value with *.decode('Hi!'), which returns the result wrapped in an instance of Ok.

Why are we wrapping the result in an Ok instance? because in case of failure we would wrap the result in an Err instance.
Let's see how the decode() signature looks like:

decode(json: any): Result<a>

Result<a> is a union type of Ok and Err.

type Result<a> = Ok<a> | Err;

So most of the time we won't be using decode(), instead we'll probably want to use decodePromise().
Let's see how the decodePromise() signature looks like:

decodePromise<b>(json: any): Promise<a>

Let's try decoding a string from start to finish using decodePromise():

import { JsonDecoder } from 'ts.data.json';

const json = Math.random() > 0.5 ? 'Hi!' : null;
JsonDecoder.string.decodePromise(json)
  .then(value => {
    console.log(value);
  })
  .catch(error => {
    console.log(error);
  });

Half of the time we'll go through the then() route and get Hi!, and half of the time we'll go through the catch() route get null is not a valid string.

Now that we know the basics let's get serious and build our custom User decoder.

The `User` decoder

Aside from the primitive decoders:

JsonDecoder.string: Decoder<string>
JsonDecoder.number: Decoder<number>
JsonDecoder.boolean: Decoder<boolean>

there are also other more complex decoders, and for our User we'll be using the JsonDecoder.object decoder:

JsonDecoder.object<a>(decoders: DecoderObject<a>, decoderName: string): Decoder<a>

What's that Decoder<a> thing all decoders are returning?

Decoders have the logic to decode a particular value, but they don't know how to execute it, this is what the Decoder class is for.
Decoder<a> has methods to execute, unwrap, chain and transform decoders / decoder values.

Let's try decoding a User from start to finish using all the tricks we've learned so far:

import { JsonDecoder } from 'ts.data.json';

interface User {
  firstName: string;
  lastName: string;
}

const userDecoder = JsonDecoder.object<User>(
  {
    firstName: JsonDecoder.string,
    lastName: JsonDecoder.string
  },
  'User'
);

const validUser = {
  firstName: 'Nils',
  lastName: 'Frahm'
};

const invalidUser = {
  firstName: null,
  lastName: 'Wagner'
};

const json = Math.random() > 0.5 ? validUser : invalidUser;

userDecoder
  .decodePromise(json)
  .then(value => {
    console.log(value);
  })
  .catch(error => {
    console.log(error);
  });

Half of the time we'll get {firstName: "Nils", lastName: "Frahm"} and half of the time we'll get <User> decoder failed at key "firstName" with error: null is not a valid string. JsonDecoder has us covered.

Going down the rabbit hole

We just started to scratch the surface of what this library is capable of, there are decoders for every type you could imagine. You can also decode:

arrays
dictionaries
recursive data structures
null
undefined

and other fancy stuff.

Go to the GitHub repo and find out!

Reusing ngrx reducers using higher-order functions

Joan Llenas Masó — Sun, 22 Jul 2018 18:05:07 +0000

Reducers are pure functions that specify how the application's state changes in response to actions sent to the store.

Usually, there's a one to one relationship between a store key and a reducer, but what happens when you want to use the same reducer logic in more than one place because, for example, you need various instances of the reducer output?

Higher-order functions

So, what are higher-order functions (HoF) anyway?

Functions that operate on other functions, either by taking them as arguments or by returning them, are called higher-order functions. (source)

There's nothing remarkable about that, but this statement is what makes such functions special:

Higher-order functions allow us to abstract over actions, not just values. (source)

Higher-order functions allow you to declare what stuff is instead of defining steps that change some state.
While a composition of higher-order functions carries semantic overload, a sequential manipulation of values carries a cognitive overload. You pick one.

HoF and reducers

A higher-order reducer is a function that returns a (configured) reducer.

Higher order reducers allow us to parametrize which actions are accepted by a reducer.
There are several strategies to achieve that. We'll take a look at a couple of them and see each one's pros and cons.

First of all, I encourage you to have a look at the basic (without higher-order reducers) canonical example that we're going to be using: the counter application. (stackblitz link)

Dynamically creating action names

Our first higher-order reducer will use a straightforward technique. We will configure the reducer by dynamically defining which action types accept.( stackblitz link )

Let's see how the modified counter.component.ts looks like:

@Component({
  selector: 'counter',
  template: `
    <button (click)="increment()">Increment</button>
    <div>Current Count: {{ count$ | async }}</div>
    <button (click)="decrement()">Decrement</button>

    <button (click)="reset()">Reset Counter</button>
  `,
})
export class CounterComponent implements OnInit {
  @Input() counterName: string;
  count$: Observable<number>;

  constructor(private store: Store<AppState>) {}

  ngOnInit() {
    this.count$ = this.store.pipe(select(this.counterName));
  }

  increment() {
    this.store.dispatch({ type: `${this.counterName}.${INCREMENT}` });
  }

  decrement() {
    this.store.dispatch({ type: `${this.counterName}.${DECREMENT}` });
  }

  reset() {
    this.store.dispatch({ type: `${this.counterName}.${RESET}` });
  }
}

The critical change here is the fact that our component now accepts a counterName input, which will define the name of the store key that this component will be using as the data source and also what prefix the action type will have.

And this is how we use the counter component in the app.component.html template:

<counter [counterName]="'counter1'"></counter>
<hr>
<counter [counterName]="'counter2'"></counter>

Note that we have added two instances of the component. Each will be using its own dynamically created reducer.

Lets' see how the higher-order reducer looks like:

counter.reducer.ts

export const INCREMENT = 'INCREMENT';
export const DECREMENT = 'DECREMENT';
export const RESET = 'RESET';


export function counterReducer(counterName: string) {
  const initialState = 0;

  return function reducer(state: number = initialState, action: Action) {
    switch (action.type) {
      case `${counterName}.${INCREMENT}`:
        return state + 1;

      case `${counterName}.${DECREMENT}`:
        return state - 1;

      case `${counterName}.${RESET}`:
        return 0;

      default:
        return state;
    }
  }
}

The higher-order reducer differs from the original implementation in three aspects:

It returns the reducer function, not the new state.
It wraps its state in the closure scope.
The matched reducer action types are defined by prefixing the original action type with the parametrized counterName (this is flexible, others prefer suffixes, you have to be consistent). There's not much more to say.

Last but not least, we need to change the Store configuration. We need to add the store keys and use the higher-order reducer to assign their value.

app.module.ts

@NgModule({
  imports: [
    BrowserModule,
    StoreModule.forRoot({ 
      counter1: counterReducer('counter1'),
      counter2: counterReducer('counter2')
    })
  ],
  declarations: [AppComponent, CounterComponent],
  bootstrap: [AppComponent]
})
export class AppModule { }

And that's pretty much it.
The counterReducer('...') function returns a new reducer each time it's called, and this reducer accepts action types in the form [actionName].[action.type].

Filtering actions by its payload

Very quickly, now that we understand the mechanism let's see another more type-safe strategy to implement higher-order reducers.
The philosophy is the same, but we'll be using action creators instead of dynamic action type names, and we'll also be adding more types to the table. (stackblitz link)

The differences between this project and the more dynamic one reside in just two files:

counter.reducer.ts

export const INCREMENT = 'INCREMENT';
export const DECREMENT = 'DECREMENT';
export const RESET = 'RESET';


// Action interface for higher-order reducers

interface CounterAction extends Action {
  actionPrefix: string;
}


// Action creators

export class Increment implements CounterAction {
  type = INCREMENT;
  constructor(public actionPrefix: string) { }
}

export class Decrement implements CounterAction {
  type = DECREMENT;
  constructor(public actionPrefix: string) { }
}

export class Reset implements CounterAction {
  type = RESET;
  constructor(public actionPrefix: string) { }
}

export type CounterActions =
  | Increment
  | Decrement
  | Reset;


// Reducer

export function counterReducer(actionPrefix: string) {
  const initialState = 0;

  function reducer(state: number = initialState, action: CounterActions) {
    switch (action.type) {
      case INCREMENT:
        return state + 1;

      case DECREMENT:
        return state - 1;

      case RESET:
        return 0;

      default:
        return state;
    }
  }

  return (state: number = initialState, action: CounterActions) => {
    switch (action.actionPrefix) {
      case actionPrefix:
        return reducer(state, action);
      default:
        return state;
    }
  }
}

A lot has changed here. Fortunately, there aren't many changes in the other file.

counter.component.ts

@Component({
  selector: 'counter',
  template: `
    <button (click)="increment()">Increment</button>
    <div>Current Count: {{ count$ | async }}</div>
    <button (click)="decrement()">Decrement</button>

    <button (click)="reset()">Reset Counter</button>
  `,
})
export class CounterComponent implements OnInit {
  @Input() counterName: string;
  count$: Observable<number>;

  constructor(private store: Store<AppState>) {}

  ngOnInit() {
    this.count$ = this.store.pipe(select(this.counterName));
  }

  increment() {
    this.store.dispatch(new Increment(this.counterName));
  }

  decrement() {
    this.store.dispatch(new Decrement(this.counterName));
  }

  reset() {
    this.store.dispatch(new Reset(this.counterName));
  }
}

The main difference is that we have introduced the action creators, which satisfy the newly added CounterAction interface and makes the actionPrefix property mandatory for all its implementors.
Also, the CounterActions type allows us to be much more specific about which actions the reducer accepts.

Pros and cons

Dynamically creating action names

Pros
- Very straightforward.
Cons
- It lacks type safety.

Filtering actions by its payload

Pros
- Typesafe.
Cons
- More verbose.

Some links

Read the Eloquent Javascript book chapter about higher-order functions
The Redux documentation has an excellent description of what a higher reducer is and does.

Controlled number input with Floats in Elm

Joan Llenas Masó — Wed, 18 Jul 2018 20:19:27 +0000

The term controlled is taken from the React documentation, but it's also applicable to Elm.
In the context of forms controlled means that the model manages the input field value so, when we type something, the change is propagated to the model and, immediately after that, the input value is also updated.

The Problem

Controlled inputs work well when the value they hold is a string, but we can't state the same when the value is a number.

Contrived example

( Ellie link )

module Main exposing (..)

import Html exposing (..)
import Html.Attributes as Attrs exposing (..)
import Html.Events exposing (..)




type Msg
    = SetPrice String


type alias Model =
    { price : Float }


model : Model
model =
    { price = 0 }


update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    case msg of
        SetPrice price ->
            ( { model | price = price |> String.toFloat |> Result.withDefault 0 }
            , Cmd.none 
            )


view : Model -> Html Msg
view model =
    div []
        [ Html.form [] 
            [ label [] [text "Price"]
            , input [placeholder "Price", value (toString model.price), onInput SetPrice ] []
            , br [] []
            , p [] [ text ("Price is: " ++ (toString model.price)) ]
            ]
        ]


main : Program Never Model Msg
main =
    Html.program
        { init = ( model, Cmd.none )
        , update = update
        , subscriptions = \_ -> Sub.none
        , view = view
        }

The main issue here is that the string -> float conversion only allows valid numbers, so any intermediate step that creates an invalid number gets converted to 0.

Issues with this approach

You can't have an empty input field, it always displays 0.
When you type a non-numeric character by mistake, the whole number is deleted.
You can't type decimals because the decimal separator . is stripped after the string -> float conversion.
You can't type negative numbers because the negative symbol - is stripped after the string -> float conversion.

Research

I have found a few solutions to this problem:

Html Number Form Inputs (https://discourse.elm-lang.org/t/html-number-form-inputs/740)
Various solutions for solving the Elm Guide age exercise (http://www.bravo-kernel.com/2016/06/various-solutions-for-solving-the-elm-guide-age-exercise/)
Use defaultValue instead of value.

But all of them have failed to satisfy my needs.

My contribution

My solution must satisfy the following:

The input type must be text because I have to support iOS and Android, where the input type number support is poor.
The record value that feeds the input must be a Float, not a String.
The input field may be empty.
All that and, ultimately, fix all the typing issues stated above.

( Ellie link )

module Main exposing (..)

import Html exposing (..)
import Html.Attributes as Attrs exposing (..)
import Html.Events exposing (..)


type Msg
    = SetPrice String


type PriceField
    = PriceField (Maybe Float) String


type alias Model =
    { price : PriceField }


model : Model
model =
    { price = PriceField Nothing "" }


update : Msg -> Model -> ( Model, Cmd Msg )
update msg model =
    case msg of
        SetPrice price ->
            if String.right 1 price == "." then
                ( { model | price = PriceField Nothing price }, Cmd.none )
            else
                let
                    maybePrice =
                        price |> String.toFloat |> Result.toMaybe
                in
                case maybePrice of
                    Nothing ->
                        ( { model | price = PriceField Nothing price }, Cmd.none )

                    Just p ->
                        ( { model | price = PriceField (Just p) price }, Cmd.none )


priceFieldToString : PriceField -> String
priceFieldToString priceField =
    case priceField of
        PriceField Nothing price ->
            price

        PriceField (Just price) _ ->
            toString price


view : Model -> Html Msg
view model =
    div []
        [ Html.form []
            [ label [] [ text "Price" ]
            , input [ placeholder "Price", value (priceFieldToString model.price), onInput SetPrice ] []
            , br [] []
            , small [] [ text ("Price is: " ++ toString model.price) ]
            ]
        ]


main : Program Never Model Msg
main =
    Html.program
        { init = ( model, Cmd.none )
        , update = update
        , subscriptions = \_ -> Sub.none
        , view = view
        }

Recap

The key here is the PriceField product type which allows us to have both the input String value and the Maybe Float at the same place.

We can also use the Maybe Float as an indicator of invalid input state, so we can add custom validation logic:

( Ellie link - same solution with some basic validation )

-- (...)
priceValidationStyle : PriceField -> List ( String, String )
priceValidationStyle priceField =
    case priceField of
        PriceField Nothing price ->
            if price == "" then
                []
            else
                [ ( "background-color", "red" ) ]

        PriceField (Just price) _ ->
            []


view : Model -> Html Msg
view model =
    div []
        [ Html.form []
            [ label [] [ text "Price" ]
            , input [ placeholder "Price", value (priceFieldToString model.price), onInput SetPrice, style (priceValidationStyle model.price) ] []
            , br [] []
            , small [] [ text ("Price is: " ++ toString model.price) ]
            ]
        ]

-- (...)

I can imagine how this same strategy could be used to add more advanced validation information to the same type, but this is all I have for now.

If you know any, I'd love to hear what other strategies or packages can be used to achieve similar goals.

DEV Community: Joan Llenas Masó

Web components: composition techniques

Table of contents

Dropdown structure

Composing a dropdown

The project

The index.html file

The main.js module

The style.css file

The <my-button> web component

::slotted

The <my-dropdown> web component

The part and exportparts attributes

::part()

The <my-dropdown-option> web component

Recap

Project code

Related things worth exploring

A few links

Web components: styles piercing shadow DOM

:host

Theming with CSS variables

Theming the <my-button> component

Coming up next

Web components: templates and shadow DOM

HTML templates

Content projection with <slot>

Shadow DOM

Putting it all together

Coming up next

Web components: custom elements

Custom elements

Iteration 1: The simplest custom element

Iteration 2: Declarative component API with attributes

Coming up next

DRY Typescript types

Indexed type access

Indexed type access + instances

Indexed type access + Generics

Indexed type access + tuples

Working with keys

Wrapping up

RemoteData, slaying a UI Antipattern with Angular

What we are trying to solve

The traditional approach

The RemoteData approach

Library resources

Decoding JSON with Typescript

Runtime vs Compile time

Enter Json decoders

State-of-the-art JSON decoder libraries

Using JSON decoders

Decoding basics

Unwrapping decoder results

The User decoder

What's that Decoder<a> thing all decoders are returning?

Going down the rabbit hole

Reusing ngrx reducers using higher-order functions

Higher-order functions

HoF and reducers

Dynamically creating action names

Filtering actions by its payload

Pros and cons

Dynamically creating action names

Filtering actions by its payload

Some links

Controlled number input with Floats in Elm

The Problem

Contrived example

Issues with this approach

Research

My contribution

Recap

The `index.html` file

The `main.js` module

The `style.css` file

The `<my-button>` web component

`::slotted`

The `<my-dropdown>` web component

The `part` and `exportparts` attributes

The `<my-dropdown-option>` web component

Theming the `<my-button>` component

Content projection with `<slot>`

The `User` decoder

What's that `Decoder<a>` thing all decoders are returning?