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

Congratulations! You've completed the exercises included in Fullstack Web Components. You coded several UI components using the set of specifications known as Custom Elements v1. You used Shadow DOM to encapsulate a component's HTML template and CSS styling. Upon further investigation of custom elements v1, you found that only autonomous and form-associated custom elements can leverage Shadow DOM. Customized built-in elements lack this capability due to how built-ins extend from common HTML elements, some of which either lack the ability to employ Shadow DOM, or in the case of 

, already utilize Shadow DOM and cannot be overwritten. While this may diminish the use-value of customized built-ins, you developed against this specification with some novel use cases: 

 to name a couple. While autonomous custom elements enable the creation of fully custom user interfaces, customized built-ins allow engineers to inherit the accessibility and other user experience characteristics from HTML elements. Through the use of 

, form-associated custom elements enable engineers to develop feature-rich custom implementations of elements that can participate in HTML forms. In the final chapter, you used Declarative Shadow DOM to server-side render custom elements. Declarative Shadow DOM allows Shadow DOM to be declared entirely in a HTML template, opening up the possibility for custom elements to be statically rendered.

One of the potential hazards developing against browser specifications like custom elements v1 is that modern browsers implement specifications at different times, or potentially not at all. Such is the case with the customized built-in elements specification which 

. While customized built-ins may never be included in Apple Safari, 

 that brings the specification to the Safari browser. Polyfills patch functionality that doesn't exist in a web browser yet, while ponyfills provides that functionality in a module that usually executes after DOM has loaded. A ponyfill needs to statically analyze DOM to function, while a polyfill grants the functionality to the browser before DOM is parsed. Both ponyfills and polyfills are useful for custom element development as different specifications are introduced in web browsers over time.

Specifications can come and go. As browser vendors and members of the community propose new specifications, a browser may introduce a specification while others linger. One of the critiques of Web Components has been that specifications are unstable. While that may have been true during custom elements v0, a legacy specification that is not covered in this book, custom elements v1 is here to stay. The specifications engineers should be concerned with moving forward are those that augment the experience of developing custom elements. To illustrate how to navigate this terrain of web specifications, let's look at how CSS specifications have either been successful or failed to catch on.

As we observed in the exercises of this book, CSS variables can pierce the shadow boundary and help style custom elements. It would be rather limiting if CSS variables were the only tool for styling custom elements. Early in the development of the custom elements specifications, other CSS selectors were proposed that pierced the shadow boundary (>>>, /deep/, and ::shadow), but they failed to gain traction as a standard. These selectors would have enabled a custom element to style slotted descendants through a special CSS selector. 

 were designed, in part, to address the concerns over implementing these aforementioned selectors in various browsers. CSS Shadow Parts allow engineers to declare parts of a HTML template that can be styled outside of the custom element's shadow boundary. While CSS Shadow Parts help CSS authors style a component from the outside, which could be useful for theming or styling a child element from a parent, this specification still doesn't address a problem with styling custom elements: the duplication of CSS styles throughout the codebase. Another specification named 

 aims to solve this problem by giving engineers a way to compose CSS for a custom element without the need to create a CSS stylesheet. At the time of writing this, CSS variables and CSS Shadow Parts are available in every mainstream browser, while Constructable Stylesheets are only found in Google Chrome, Microsoft Edge and behind a flag in Mozilla Firefox. This bodes well for the specification. Most browsers have signaled Constructable Stylesheets will be implemented and for those browsers which lag, 

 that brings the functionality to that browser. Over time, the specifications that support styling custom elements have evolved, giving engineers greater flexibility when authoring elements that employ Shadow DOM.

It can often be confusing determining if a particular specification can be used in a specific browser. The Web Platform Incubator Community Group provides 

 is also a useful tool for determining the viability of a particular specification. One source of confusion happens when a browser fails to signal if they intend to implement a specification, as is often the case with Apple Safari. Searching for a particular specification's polyfill may also yield information as the maintainers of the polyfill or ponyfill are keenly aware of browser support.

Another promising specification includes the 

 which brings data binding to HTML templates. A 

 exists to support these "Template Parts". The 

 serves to provide a means to pass data between components. If adopted by mainstream browsers, this specification would replace the need for 

 which we used in this book for the same purpose. The 

 would alleviate issues with custom elements that have asynchronous dependencies. While a pattern for hydration exists as part of the implementation of Declarative Shadow DOM, 

 would provide finer grained control over what should trigger hydration of a custom element. All of these specifications are indeed very promising. While some enterprising engineers may develop a polyfill when it doesn't exist yet, the rest of us should check the status of a specification, if a polyfill or ponyfill exists before developing against the specification.

---
title: Conclusion
description: The conclusion of the book Fullstack Custom Elements.
role: "CONCLUSION"
isPublicLesson: true
---

# Conclusion

Congratulations! You've completed the exercises included in Fullstack Web Components. You coded several UI components using the set of specifications known as Custom Elements v1. You used Shadow DOM to encapsulate a component's HTML template and CSS styling. Upon further investigation of custom elements v1, you found that only autonomous and form-associated custom elements can leverage Shadow DOM. Customized built-in elements lack this capability due to how built-ins extend from common HTML elements, some of which either lack the ability to employ Shadow DOM, or in the case of `HTMLVideoElement`, already utilize Shadow DOM and cannot be overwritten. While this may diminish the use-value of customized built-ins, you developed against this specification with some novel use cases: `ButtonComponent` and `TableComponent` to name a couple. While autonomous custom elements enable the creation of fully custom user interfaces, customized built-ins allow engineers to inherit the accessibility and other user experience characteristics from HTML elements. Through the use of `ElementInternals`, form-associated custom elements enable engineers to develop feature-rich custom implementations of elements that can participate in HTML forms. In the final chapter, you used Declarative Shadow DOM to server-side render custom elements. Declarative Shadow DOM allows Shadow DOM to be declared entirely in a HTML template, opening up the possibility for custom elements to be statically rendered.

## Specification

One of the potential hazards developing against browser specifications like custom elements v1 is that modern browsers implement specifications at different times, or potentially not at all. Such is the case with the customized built-in elements specification which [the WebKit team has vehemently rejected](https://github.com/WICG/webcomponents/issues/509#issuecomment-224212371). While customized built-ins may never be included in Apple Safari, [a polyfill exists](https://github.com/ungap/custom-elements#readme) that brings the specification to the Safari browser. Polyfills patch functionality that doesn't exist in a web browser yet, while ponyfills provides that functionality in a module that usually executes after DOM has loaded. A ponyfill needs to statically analyze DOM to function, while a polyfill grants the functionality to the browser before DOM is parsed. Both ponyfills and polyfills are useful for custom element development as different specifications are introduced in web browsers over time.

Specifications can come and go. As browser vendors and members of the community propose new specifications, a browser may introduce a specification while others linger. One of the critiques of Web Components has been that specifications are unstable. While that may have been true during custom elements v0, a legacy specification that is not covered in this book, custom elements v1 is here to stay. The specifications engineers should be concerned with moving forward are those that augment the experience of developing custom elements. To illustrate how to navigate this terrain of web specifications, let's look at how CSS specifications have either been successful or failed to catch on.

As we observed in the exercises of this book, CSS variables can pierce the shadow boundary and help style custom elements. It would be rather limiting if CSS variables were the only tool for styling custom elements. Early in the development of the custom elements specifications, other CSS selectors were proposed that pierced the shadow boundary (>>>, /deep/, and ::shadow), but they failed to gain traction as a standard. These selectors would have enabled a custom element to style slotted descendants through a special CSS selector. [CSS Shadow Parts](https://www.w3.org/TR/css-shadow-parts-1/) were designed, in part, to address the concerns over implementing these aforementioned selectors in various browsers. CSS Shadow Parts allow engineers to declare parts of a HTML template that can be styled outside of the custom element's shadow boundary. While CSS Shadow Parts help CSS authors style a component from the outside, which could be useful for theming or styling a child element from a parent, this specification still doesn't address a problem with styling custom elements: the duplication of CSS styles throughout the codebase. Another specification named [Constructable Stylesheets](https://github.com/WICG/construct-stylesheets/blob/main/explainer.md) aims to solve this problem by giving engineers a way to compose CSS for a custom element without the need to create a CSS stylesheet. At the time of writing this, CSS variables and CSS Shadow Parts are available in every mainstream browser, while Constructable Stylesheets are only found in Google Chrome, Microsoft Edge and behind a flag in Mozilla Firefox. This bodes well for the specification. Most browsers have signaled Constructable Stylesheets will be implemented and for those browsers which lag, [a polyfill exists](https://github.com/calebdwilliams/construct-style-sheets) that brings the functionality to that browser. Over time, the specifications that support styling custom elements have evolved, giving engineers greater flexibility when authoring elements that employ Shadow DOM.

It can often be confusing determining if a particular specification can be used in a specific browser. The Web Platform Incubator Community Group provides [a spreadsheet](https://docs.google.com/spreadsheets/d/1K2EtkvKXMDk_h2goR34uMIWmw1LfPhIi-QAJHcQBP_4/edit#gid=0) with the status of each specification. [Chrome Platform Status](https://chromestatus.com/features) is also a useful tool for determining the viability of a particular specification. One source of confusion happens when a browser fails to signal if they intend to implement a specification, as is often the case with Apple Safari. Searching for a particular specification's polyfill may also yield information as the maintainers of the polyfill or ponyfill are keenly aware of browser support.