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

Express.js is a popular Node.js framework that handles common use cases for server-side web development like handling http requests, routing, templating, and debugging. This project uses Express.js to provide backend API services for the web application. When the web application made HTTP requests to 

 for instance, Express handled that request, checked the username and password against a database, then sent a response depending on the validity of the username and password. Express uses middleware to achieve this. API middleware defined in the file 

 handles multiple types of HTTP requests following REST API design guidelines. That middleware is then imported and injected into the Express application in the entry point (

import apiRouter from './middleware/api.js';
...
const app = express();
...
app.use('/api', apiRouter);

 is imported into the entry point of the Express application. The application is instantiated by calling 

. Afterward, middleware can be declared for the Express application. Whenever a HTTP request is made at 

Most of the development of the Express server was handled for you. This was done so you could concentrate on coding custom elements, with one notable exception: Express middleware that handles server-side rendering Declarative Shadow DOM HTML templates. To achieve this, you'll develop the Express middleware that handles server-side rendered HTML responses at the following routes:

Right now, every request by default loads the 

 of the client-side application. This was necessary because in the previous chapter you were dealing with a single-page application.

app.get("/*", (req, res) => {
  res.sendFile(clientPath("index.html"));
});

Later in this chapter, you'll deprecate that handling of the SPA. After importing the 

 middleware, you'll map the HTTP requests for the three routes to the middleware.

import ssr from "./middleware/ssr.js";
...
app.get("/", ssr);
app.get("/login", ssr);
app.get("/dashboard", ssr);

Development in this section is done like any other before it. You may continue by running the command 

 which starts both the client and server development environments.

Before working on the Express middleware, there's still a bit of preparation work that needs to be done on the client. You recently deprecated the client-side SPA router, but left the 

 around to use them in the context of the server-side renderer. It wasn't made apparant at the time, but this change was necessary to expose the Declarative Shadow DOM HTML templates somewhere that mapped each template to a given route.

 configuration already defines the route of each view, but you'll need to add the template for each 

 to the configuration, so later you can use this configuration in the Express middleware. In 

, import all three of the templates from their respective files.

import { template as dashboardTemplate } from "./view/dashboard/DashboardView";
import { template as loginTemplate } from "./view/login/LoginView";
import { template as mainTemplate } from "./view/main/MainView";

, specifying the HTML template for each view to the route it should map to. For instance, 

 is the Declarate Shadow DOM HTML template that should render at 

 should display when the user navigates to 

export const routes = [
  {
    path: "/",
    component: "main",
    tag: "main-view",
    title: "In",
    template: mainTemplate,
  },
  {
    path: "/login",
    component: "login",
    tag: "login-view",
    title: "Login",
    template: loginTemplate,
  },
  {
    path: "/dashboard",
    component: "dashboard",
    tag: "dashboard-view",
    title: "Contact Dashboard",
    template: dashboardTemplate,
  },
];

With that configuration complete on the client, it's time to code the Express middleware.

To get started coding the Express middleware that will server-side render each view, make a new file named 

touch packages/server/src/middleware/ssr.js

 you just exported from the client application using a relative path for now. This could very well be done using the package name 

import { routes } from "./../../../client/dist/index.js";

, you'll have to wrangle paths to different files. You're going to write some code that reads the content of several .html, .css, and .js files and then prints the content of those files to a server-side rendered template. To deal with the paths to those files in the local filesystem, import 

 from fs, which will be used to read the content of a file at a given path on the local filesystem.

If you haven't already, build the project before proceeding to ensure all packages are built property and their distributed files can be read by the Express server.

Most of the files that should be returned in the response of the HTML document are found in one of two locations: 

s that return the path of a file from either of these two directories. Inject the filename into the first argument of the 

 to return the path of the file, relative to where the script is run. 

 returns the path where the server is run (

). Use a relative path to find the dist directories of the 

 argument to the end of the path, so the 

const clientPath = (filename) =>
  resolve(`${process.cwd()}../../client/dist/${filename}`);
const stylePath = (filename) =>
  resolve(`${process.cwd()}../../style/dist/${filename}`);

 that return the content of the file at the path returned by either 

 will read the content of the file synchronously. By calling 

 you can easily convert the file contents to a 

const readClientFile = (filename) =>
  readFileSync(clientPath(filename)).toString();
const readStyleFile = (filename) =>
  readFileSync(stylePath(filename)).toString();

In the next part you'll read the content of files in the 

 packages, then minify the content for performance reasons, before inserting the content into the HTML document.

Before handling the Declarative Shadow DOM templates, we need to figure out a way to render the global CSS styling that contains CSS variables used in every component and the HTML templates that can be referenced by any component. The CSS styles are available in the file at 

s that can read the content of files in these directories, although there's still some processing of these files that needs to happen. Minifying the content of 

 will help reduce the size of the overall HTML document, making it faster for browsers to request the document. To minify the content of both files, import 

import { minify } from "html-minifier-terser";

, passing in the file content returned by 

---
title: Express Middleware
description: You'll develop Express middleware that server-side renders Declarative Shadow DOM HTML Templates with @lit-labs/ssr.
isPublicLesson: true
---

## Express Middleware

Express.js is a popular Node.js framework that handles common use cases for server-side web development like handling http requests, routing, templating, and debugging. This project uses Express.js to provide backend API services for the web application. When the web application made HTTP requests to `/api/login` for instance, Express handled that request, checked the username and password against a database, then sent a response depending on the validity of the username and password. Express uses middleware to achieve this. API middleware defined in the file `packages/server/src/middleware/api.js` handles multiple types of HTTP requests following REST API design guidelines. That middleware is then imported and injected into the Express application in the entry point (`packages/server/src/index.js`).

```javascript
import apiRouter from './middleware/api.js';
...
const app = express();
...
app.use('/api', apiRouter);
```

In the above example, the instance of `express.Router` defined in `packages/server/src/middleware/api.js` is imported into the entry point of the Express application. The application is instantiated by calling `express()`. Afterward, middleware can be declared for the Express application. Whenever a HTTP request is made at `/api`, the `apiRouter` will handle the request.

Most of the development of the Express server was handled for you. This was done so you could concentrate on coding custom elements, with one notable exception: Express middleware that handles server-side rendering Declarative Shadow DOM HTML templates. To achieve this, you'll develop the Express middleware that handles server-side rendered HTML responses at the following routes:

-   /
-   /login
-   /dashboard

Right now, every request by default loads the `index.html` of the client-side application. This was necessary because in the previous chapter you were dealing with a single-page application.

```javascript
app.get("/*", (req, res) => {
  res.sendFile(clientPath("index.html"));
});
```

Later in this chapter, you'll deprecate that handling of the SPA. After importing the `ssr` middleware, you'll map the HTTP requests for the three routes to the middleware.

```javascript
import ssr from "./middleware/ssr.js";
...
app.get("/", ssr);
app.get("/login", ssr);
app.get("/dashboard", ssr);
```

Development in this section is done like any other before it. You may continue by running the command `yarn start:app` which starts both the client and server development environments.

### Client

Before working on the Express middleware, there's still a bit of preparation work that needs to be done on the client. You recently deprecated the client-side SPA router, but left the `routes` around to use them in the context of the server-side renderer. It wasn't made apparant at the time, but this change was necessary to expose the Declarative Shadow DOM HTML templates somewhere that mapped each template to a given route.

The `Route` configuration already defines the route of each view, but you'll need to add the template for each `Route` to the configuration, so later you can use this configuration in the Express middleware. In `packages/client/src/routes.ts`, import all three of the templates from their respective files.

```typescript
import { template as dashboardTemplate } from "./view/dashboard/DashboardView";
import { template as loginTemplate } from "./view/login/LoginView";
import { template as mainTemplate } from "./view/main/MainView";
```

Add a new property to each `Route` called `template`, specifying the HTML template for each view to the route it should map to. For instance, `mainTemplate` is the Declarate Shadow DOM HTML template that should render at `/`, while `dashboardTemplate` should display when the user navigates to `/dashboard`.

```typescript
export const routes = [
  {
    path: "/",
    component: "main",
    tag: "main-view",
    title: "In",
    template: mainTemplate,
  },
  {
    path: "/login",
    component: "login",
    tag: "login-view",
    title: "Login",
    template: loginTemplate,
  },
  {
    path: "/dashboard",
    component: "dashboard",
    tag: "dashboard-view",
    title: "Contact Dashboard",
    template: dashboardTemplate,
  },
];
```

With that configuration complete on the client, it's time to code the Express middleware.

### Server

To get started coding the Express middleware that will server-side render each view, make a new file named `ssr.js` in the `packages/server/src/middleware` directory.

```bash
touch packages/server/src/middleware/ssr.js
```

Import the `routes` you just exported from the client application using a relative path for now. This could very well be done using the package name `@in/client`, assuming that package is built.

```javascript
import { routes } from "./../../../client/dist/index.js";
```

In this first part of the `ssr.js`, you'll have to wrangle paths to different files. You're going to write some code that reads the content of several .html, .css, and .js files and then prints the content of those files to a server-side rendered template. To deal with the paths to those files in the local filesystem, import `resolve` from path.

```javascript
import { resolve } from "path";
```

Import `readFileSync` from fs, which will be used to read the content of a file at a given path on the local filesystem.

```javascript
import { readFileSync } from "fs";
```

If you haven't already, build the project before proceeding to ensure all packages are built property and their distributed files can be read by the Express server.

```bash
yarn build
```

### Read Client Bundles

Most of the files that should be returned in the response of the HTML document are found in one of two locations: `@in/client` and `@in/style` package's `dist` directories. Code two reusable `function`s that return the path of a file from either of these two directories. Inject the filename into the first argument of the `function`. Use `resolve` to return the path of the file, relative to where the script is run. `process.cwd()` returns the path where the server is run (`packages/server`). Use a relative path to find the dist directories of the `@in/client` and `@in/style` packages, passing the `filename` argument to the end of the path, so the `function` returns a path to the filename.

```javascript
const clientPath = (filename) =>
  resolve(`${process.cwd()}../../client/dist/${filename}`);
const stylePath = (filename) =>
  resolve(`${process.cwd()}../../style/dist/${filename}`);
```

Declare two similar `function` that return the content of the file at the path returned by either `clientPath` or `stylePath`. `readFileSync` will read the content of the file synchronously. By calling `toString` you can easily convert the file contents to a `string`.

```javascript
const readClientFile = (filename) =>
  readFileSync(clientPath(filename)).toString();
const readStyleFile = (filename) =>
  readFileSync(stylePath(filename)).toString();
```

In the next part you'll read the content of files in the `@in/client` and `@in/style` packages, then minify the content for performance reasons, before inserting the content into the HTML document.