Acknowledgements

The beginning of your journey with Web Components.

Foreword

A brief introduction to the set of specifications called Web Components. We'll introduce you to concepts such as Shadow DOM, HTML templates, Custom Elements v1 and uncover typical use cases for developing Web Components.

Introduction to Web Components

We'll introduce you to the mockups in Figma, the development environment used throughout the book, and other conventions used in this book.

Conventions Used In The Book

A guide for installing various technologies needed prior to coding the exercises in this book.

Setting Up The Development Environment

We'll look at what you'll learn throughout Fullstack Web Components.

Module 1 Summary

Introduction

In Part 1, you'll code a form using several Web Components specifications.

Specification

Part One

By developing the CardComponent, you'll get hands on experience with autonomous custom elements.

Autonomous custom elements

Before you can develop the CardComponent, you'll need to scaffold the component in Storybook.

Template Slots

Shadow DOM provides encapsulation for styling and template. You'll style CardComponent with CSS in the context of the autonomous custom element's Shadow DOM.

Styling CardComponent

Write integration and snapshot tests for CardComponent using Cypress and Storybook Storyshots.

Testing the card

You built an autonomous custom element with Shadow DOM, HTML templates, and ES Modules. Let's reflect on that.

Chapter One Summary

Getting to Know Web Components

Form-associated custom elements allow custom elements to participate in HTML forms. From validation to submission, you'll code a text input end-to-end.

Form-associated custom elements

Scaffold a form-associated custom element named TextInputComponent in Storybook.

TextInputComponent

You'll learn what distinguises a form-associated custom element from an autonomous custom element, the formAssociated property and ElementInternals interface.

Form Associated and ElementInternals

Form-associated custom elements don't come with a pattern that validates an entire form, so you'll implement a pattern that allows form validation.

Handling Validation

Using observedAttributes and attributeChangedCallback to listen and react to changes in custom element attributes.

Listening for attribute changes

You'll style the various interaction states of the TextInputComponent form-associated custom element.

User feedback

We've created a problem by encapsulating the HTMLInputElement by Shadow DOM. The HTMLInputElement API cann't be accessed by the outside world. In this section, you'll fix that by implementing getters and setters that emulate the HTMLInputElement on TextInputComponent.

Emulating HTMLInputElement

You'll update the Story and provide the missing APIs to TextInputComponent that allow the component to fully interact with a HTML form.

Making a form

Reviewing the work completed on the form-associated custom element TextInputComponent.

Chapter Two Summary

You'll code ButtonComponent, a customized built-in element that inherits accessibility characteristics from HTMLButtonElement.

Customized built-in elements

Scaffold the customized built-in element ButtonComponent with Storybook.

Scaffolding ButtonComponent

Customized built-ins can't benefit from the encapsulation provided by Shadow DOM, so you'll have to find another way to style ButtonComponent.

Styling ButtonComponent

Revist the HTML form by making the user experience more accessible.

Making the form accessible

How customized built-in elements can make custom elements more accessible.

Chapter Three Summary

You'll learn best practices for developing a UI Library with Web Components by coding a micro-library, developing two custom elements with the micro-library, and figuring out how to package the UI library for distribution.

UI Library

Part Two

You'll abstract common patterns intro reusable code in a micro-library powered by TypeScript Decorators.

Micro-library

How to code an interface for Web Components with TypeScript decorators that enables declaration of the selector, styles, and template.

Class Decorator

You'll code a method decorator named Listen that binds event listeners to class methods.

Method Decorator

In this chapter you learned how to code a micro-library with TypeScript decorators that streamlines Web Component development.

Chapter Four Summary

You'll investigate multiple methods for components to communicate by coding an editable table.

Component Communication

How to use mock data in Storybook to code Web Components.

Mocking Table Data in Storybook

You'll learn about three methods for custom elements to communicate, attribute drilling, CustomEvent, and BroadcastChannel.

Coding Compound Components

You'll learn about how to create a separation of concerns between the many custom elements that comprise the editable table.

Making the Table Editable

You learned about how to create a separation of concerns between various custom elements in the same user experience flow.

Summary

Compound Custom Elements

You'll learn how to code a common UX pattern (dialogs) using HTML templates and custom elements.

HTML Templates

You'll mock the DialogComponent in Storybook.

Mocking the Dialog in Storybook

You'll make a configurable dialog with custom elements.

DialogComponent

You'll scaffold two custom elements that leverage DialogComponent to display modals and tooltips.

Modal and Tooltip

You'll fix an issue faced in the last section by learning how to query for elements across Shadow boundaries.

Querying DOM Across Shadow Boundaries

You'll control the ordering and event cycle of dialogs with a custom class named DialogStack.

DialogStack

Summarizing the work completed in DialogComponent, ModalComponent, TooltipComponent, and DialogStack.

Chapter Six Summary

Powering Dialogs with HTML Templates

You'll learn best practices for organizing and distributing Web Component UI libraries.

UI Libraries

You'll learn brest practices for distributing Web Components by formatting the code with named exports, configuring the build with Rollup, providing a standard package format, and writing a custom Node.js script that enables you to publish packages.

Distribution

Custom Elements Manifest provides a wealth of information about each component. After generating a manifest, it will provide documentation for each component in Storybook.

Documentation

You'll learn how to setup continuous integration for the UI library with Github Actions.

Continuous Integration

Let's reflect on the best practices you learned for distributing UI libraries filled with Web Components.

Chapter Seven Summary

Distributing Custom Element Libraries

You'll integrate the UI library with a single-page application and code the end-to-end user experience with custom elements.

Application

Part Three

You'll provide a separation of concerns with custom elements in a single page application.

Application Development with Custom Elements

You'll scaffold the landing page with an autonomous custom element named MainView.

Landing Page

You'll code a global header with autonomous custom elements named AppHeader.

Header

You'll code another autonomous custom element that handles cookie authorization named CookieFooter.

CookieFooter

You'll lazyload an image with customized built-ins.

Background

You developed the landing page of the application, learning how to architect a separation of concerns between the UI components.

Chapter Eight Summary

To handle multiple views in the single page application, you'll need to implement a router that can navigate between each view.

Routing Custom Elements in a SPA

You'll code the Router class that handles the creation and removal of views in the application.

Routing

You'll code the necessary components and services required in the login view.

Login View

Integrate TableCardComponent into a third view of the single page application, the dashboard.

Dashboard View

You coded a single page web application with custom elements and a custom router.

Chapter Nine Summary

You'll server-side render the views of the application with Declarative Shadow DOM and @lit-labs/ssr

Server-Side Rendering Custom Elements

You'll declare a server-side renderable Declarative Shadow DOM HTML template for each component.

Declarative Shadow DOM Templates

To get custom elements to work in Node.js, you'll need to polyfill DOM APIs. Luckily, @lit-labs/ssr provides a tool that enables just that.

Shim

You'll develop Express middleware that server-side renders Declarative Shadow DOM HTML Templates with @lit-labs/ssr.

Express Middleware

You rendered custom elements server-side using Declarative Shadow DOM and @lit-labs/ssr.

Chapter Ten Summary

Server-side Rendering with Declarative Shadow DOM

The conclusion of the book Fullstack Custom Elements.

Conclusion

Fullstack Web Components

Enter your name and email address below, then click the **"Send my free chapter"** button to get started

There are several books about Web Components, but none go into how to integrate Web Components in a typical enterprise web development workflow. This book is designed to help you learn Web Components and integrate it into your work.

In this book, we cover the basics of Web Components, how to code complex user interfaces with custom elements in Storybook, how to test and maintain UI libraries built with custom elements, and how to build web applications entirely with Web Components and browser specifications. It comes with complete code examples. We walk through the entire process step-by-step.

It's taught by Stephen Belovarich, a software engineer and web developer. Stephen has provided what he's learned about UI libraries and web applications while working at Ubiquiti Networks, Norton, Nike, NBC Universal, and Workday, that can benefit other developers, students, and anyone making a website.

The Complete Guide to Building UI Libraries with Web Components

In this book, we will learn Web Components through the lens of a JavaScript developer.

The basics of working with and manipulating Web Components

The best practices for maintaining a UI library made of custom elements

How to create a micro-library for Web Components with TypeScript Decorators

What problems Web Components can solve in everyday development

How to build web applications entirely from Web Components and JavaScript

In the nineties web development was egalitarian. HTML provided a syntax anyone could learn. A 

 attribute has a valid address for an image file. The HTML standard evolved over time, however the elements used in development in the nineties still work today.

What it takes to develop a website has dramatically changed over the years. Web development became even more sophisticated when corporations discovered an advantage web had over native: anyone can access software in a web browser and updates can be pushed server-side, without the need for the end-user to trigger a software update. JavaScript frameworks like React, Angular, and Vue filled in the gaps of the ECMAScript standard, giving web engineers sophisticated tools and patterns for coding feature-rich web applications. React, in particular, popularized the notion of classes with 

 before ECMAScript delivered the standards-based 

 with the ES2015 standard, otherwise known as ES6. While JavaScript frameworks created fragmentation with incompatible component models, JavaScript frameworks have one thing in common. React, Angular, and Vue all feature a discrete unit of functionality that encapsulates template, styling, and user interface behaviors called the "component".

Framework-based UI components solved a distinct problem in web development by providing a component model, but the web platform lagged behind. There was no way to create a custom HTML element. Web developers could only use the HTML elements provided by the HTML standard, and extending the prototype of a native HTML element was considered a bad practice. In web application templates, each of the frameworks allow framework components to be declared alongside HTML elements, although components from two different frameworks don't necessarily work together in the same template. The opinionated implementation of one framework component clashes with another. Rendering multiple framework components in a single architecture can become extremely brittle. It's amazing how much JavaScript frameworks provide out of-the-box, but they don't really play nice together.

The fragmentation caused by JavaScript frameworks pose a problem at scale in corporations. Maintaining a consistent look and feel across a portfolio of many web applications is seemingly impossible when several engineering teams develop with different JavaScript frameworks. The same UI component could be duplicated many times over as the component is developed specifically for each framework. Pushing out changes to design and UX behavior becomes a herculean task, dealing the dependency chain of each JavaScript framework along the way.

Supporting accessible behaviors in framework-based UI components is challenging because when developing custom UI you essentially have to reinvent the wheel. Engineers may create a button component with a framework, but mistakingly use the template of a 

 in the process. The engineer would have to implement event listeners on keydown to listen for the spacebar and return keys being pressed, adding to the complexity of the codebase they maintain. Custom elements can extend from native HTML elements, retaining the accessibility behaviors of the element they extend from. This isn't to say Web Components aren't without challenges when it comes to accessibility. Shadow DOM can block screen readers from analyzing WAI-ARIA attributes when ids are deeply nested across Shadow boundaries, so developer intervention maybe needed to coax screen readers to obtain the desired results for accessibility.

Other problems with framework-based UI component development occur over time. Breaking changes in major versions of frameworks can cause churn. As frameworks optimize over time, breaking changes to syntax or different ways of working force engineers to relearn how UI components are developed. Rarely nowadays would you see 

 in a modern React application, instead engineers would use the class-based 

 or a functional implementation with React hooks. A standards-based Web Component has a longer lifespan than framework components. Like those HTML elements 

, Web Components are part of the HTML specification. A custom element registered with the 

 will work in browsers for several years to come.

export class CardComponent extends HTMLElement {
  constructor() {
    super();
    const shadowRoot = this.attachShadow({ mode: 'open' });
    const template = document.createElement('template');
    template.innerHTML = `
      <style>
				:host {
					display: block;
					background: white;
					border-radius: 12px;
					border: 4px solid black;
          overflow: hidden;
          max-width: 320px;
          min-height: 120px;
				}
      </style>
      <header>
        <slot name="header"></slot>
      </header>
      <section>
        <slot name="body"></slot>
      </section>
      <footer>
        <slot name="footer"></slot>
      </footer>
    `;
    shadowRoot.appendChild(template.content.cloneNode(true));
  }
}
customElements.define('in-card', CardComponent);

Web Components are interoperable, meaning custom elements can be used in the context JavaScript frameworks like any other HTML element.

export {CardComponent} from "./custom-element";

export const App = () => {
  return (
    <div>
      <in-card></in-card>
    </div>
  )
}

ReactDOM.render(<App />, document.querySelector("#root"));

Custom elements created with the Web Components standard can retain the accessibility behaviors of the HTML elements they extend. A customized built-in element that extends from 

 includes all the traits of a typical HTML 

 element. When the user presses Enter or Space, the button is activated without any custom logic. This isn't to say sometimes accessibility behaviors are not necessary to implement in autonomous custom elements or form-associated custom elements.

export class ButtonComponent extends HTMLButtonElement {
  constructor() {
    super();
  }
  connectedCallback() {
   this.addEventListener('click', this.onClick);
  }
  onClick() {
    this.dispatchEvent(new CustomEvent('buttonClicked'));
  }
}

customElements.define('in-button', ButtonComponent, {extends: 'button'});

Somehow we find ourselves at a place where web development is no longer egalitarian. The learning curve for web development is absurd for anyone who just wants to put a custom element on a page. Not only does someone have to learn the component model for a particular JavaScript framework, but how to test, maintain, and deploy complex framework code. Then another framework becomes popular and engineers have to relearn everything. We call this JavaScript fatigue. Part of the problem is the fragmentation, but in my opinion, it's mostly a problem with education. If people new to web development are skipping web standards in favor of learning frameworks, they are adding complexity, without learning about how things work. HTML elements are the most primitive Object we have to deal with in web development. Anyone can start developing UI with Web Components right in the browser.

While it's not practical to develop custom elements this way in the browser, the example above is useful to demonstrate that Web Components require zero dependencies to work.

Front end web development usually requires handling templates, styling, and logic that defines the behavior of discrete functional units, commonly referred to as UI components. Web Components are a set of browser specifications that provides encapsulation and organization for user-interface logic in a standard component model. The term "custom elements" is often used interchangeably with "web components", although custom elements are just one of the specifications that comprise Web Components.

Web Components is a marketing term that refers to several browser standards maintained by the 

Web Hypertext Application Technology Working Group (WHATWG)

, documents that establish the ongoing state of Hyper Text Markup Language (HTML) and Document Object Model (DOM). WHATWG is comprised of web engineers from Apple, Google, Microsoft, Mozilla, Opera and the broader web development community. In 2019, W3C and WHATWG agreed to work together to maintain the HTML standard as a living document that constantly evolves over time.

In contrast to open source JavaScript frameworks that are maintained by corporate teams or the broader community, Web Components are developed through a rigorous standardization process. Once a particular Web Component standard is finalized, browser vendors prioritize and implement the specification. As of January 2020, all major web browsers including Apple Safari, Google Chrome, Microsoft Edge, Mozilla Firefox, and Opera implemented the major feature of 

 specification: autonomous custom elements. Other specifications under the Web Components umbrella, such as Shadow DOM and HTML templates, have been part of the HTML standard for quite some time, while some like Declarative Shadow DOM or Constructable Stylesheets have yet to be included in all major web browsers. As HTML is a living document, support changes over time and any feature that lacks support in some browsers can be polyfilled. We'll look into this in more detail later. For now, let's define the various specifications that make up Web Components.

The cornerstone of the Web Components featureset, custom elements allow new HTML tags to be defined in a web browser. 

 is the stable implementation of the custom elements specification. This standard allows you to define a new HTML element and the HTML element's JavaScript API. Other specifications like 

 extend the functionality of custom elements beyond the set of specifications known as Custom Elements v1. Custom elements allow you to observe changes to element attributes and manage content and styling for the new element's template. Custom elements behave like any other HTML element, with some syntactical sugar that promotes standardization across any custom element behavior.

There are three different types of custom elements: autonomous custom elements, customized built-in elements, and form-associated custom elements.

Autonomous custom elements allow you to define customized functionality for a 

. Autonomous custom elements extend from the 

 class. The most compatible custom element type, autonomous custom elements are available in all evergreen browsers. This specification is what people are typically referring to when describing Web Components or Custom Elements v1.

, retaining the behaviors of those elements. Customized built-in elements behave differently than autonomous custom elements, although this specification retains many of the features of autonomous custom elements. Customized built-in elements can be used in several evergreen browsers, except Apple Safari which requires a polyfill.

 that are within a custom element's Shadow DOM tree. This means form validation is precarious at best. Form-associated custom elements provide an extended API from autonomous custom elements that gives you hooks into form validation. This means you can still encapsulate a form control's template, while exposing the validity of the control to the parent 

. Form-associated custom elements open the door for the creation of truly customized user experiences that participate in HTML forms. Instead of merely relying on traditional form elements, it's now possible to make your own.

In the first part of this book, we'll investigate the similarities and differences between the different types of custom elements and see how they work together to provide complex, reusable components.

 property provides methods for registering custom elements and querying registered elements. Every custom element must be registered with the 

Shadow DOM is a browser technology that provides encapsulation for a HTML element, isolating the HTML element's template from the rest of DOM. When using Shadow DOM with custom elements, you can isolate 

: the root node of a DOM substructure rendered outside the scope of DOM. The top level element that employs Shadow DOM is considered the 

 element. In contrast to Shadow DOM, anything outside of the shadow boundary in the global scope of the 

When you query for an element on the document using 

 or similar method, you are essentially querying the entire document because the Document Object Model (DOM) has a global scope. If you wanted to style an element or enhance an element with some logic via JavaScript, you would have to inject a 

 tag in the case of JavaScript that relies on querying for DOM that is fully loaded. Because of the global nature of DOM, CSS or JavaScript intended for one HTML element could collide with another the styling or logic wasn't intended for. When developing UI components it's extremely helpful to rely on an isolated scope for the component, so CSS and JavaScript collisions can't happen.

 tag, first introduced in HTML5, allows HTML to be predefined and reused throughout DOM. HTML templates are parsed but not rendered until cloned. This behavior allows for custom element templates to be rendered performantly when HTML templates are used in conjunction with Shadow DOM.

Replacing the deprecated specification for JSON, CSS and HTML modules allow for custom elements to request resources asynchronously. Yet to be finalized the JSON, CSS and HTML modules specifications are currently in development by WHATWG and W3C.

When Shadow DOM was introduced, the only way to style a custom element's 

 from the context of Light DOM was to use CSS variables. CSS variables were the only method that pierced the Shadow boundary.