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 this section, you'll explore two ways for custom elements to communicate with one another: setting HTML attributes and sending messages over 

. First, you'll use HTML attributes to provide the channel name to both 

. Currently the channel name is set on an attribute of an instance of 

 and pass the name of the channel using attribute drilling to 

 is ultimately the component that requires the mock data to render columns and rows. You'll use the channel name passed through an attribute on 

 internally and subscribe to messages broadcast on the channel. In the story file, you'll broadcast a message that contains the mock data to 

Custom elements have robust ways to listen for changes on HTML attributes (

). Setting HTML attributes on a custom element is a perfectly viable way to communicate with the element, provided the element is queriable. Since 

 has several HTML template slots you can set content.

@Component({
  selector: 'in-tablecard',
  style: css``,
  template: html`
    <in-card>
      <table is="in-table" slot="content"></table>
      <div class="table-footer" slot="footer"></div>
    </in-card>
  `,
})

 is a customized built-in element, so you can use it like any other 

 so the table displays in the main content area of the card. Next, add a 

. You'll use the class name later to style the footer.

 so you can use the component in the context of the story.

import { CardComponent } from "./../card/Card";

 to satisfy Storybook's Webpack compilation.

export { CardComponent, TableCardComponent, TableComponent, ColumnData };

. This enables the custom element to listen for changes on a HTML attribute with the name 

static get observedAttributes() {
  return ['channel'];
}

 you'll first need to select the instance of 

. An easy way to do this is via a getter on 

 strictly typed by setting the return type of the getter method to 

 in the getter method. You need to query for the 

 is an autonomous custom element employing Shadow DOM.

get $table(): HTMLTableElement {
  return this.shadowRoot.querySelector('table');
}

 and store the instance on a new property of 

 method to react to changes to the value of the 

 HTML attribute. Just like in previous chapters, use the 

 arguments of the attributeChangedCallback

requires a channel name, at the very least. We'll leave the

here for later, in case we need to react to messages on the channel in

attributeChangedCallback(name, prev, next) {
  switch (name) {
    case 'channel':
      this.channel = new BroadcastChannel(next);
      this.$table.setAttribute('channel', next);
      break;
  }
}

, we still need a way to listen for changes to the 

 to listen for messages on the channel. Setup a property on the 

 and listen for messages. Set the value of 

attributeChangedCallback(name, prev, next) {
  switch (name) {
    case 'channel':
      this.channel = new BroadcastChannel(next);
      this.channel.onmessage = this.onMessage.bind(this);
      break;
  }
}

 behaves like other event listeners. Whenever a message is broadcast on the channel, an event passes through the first argument of 

 temporarily to easily inspect messages on 

onMessage(ev) {
  console.log(ev.data);
}

 but nothing is actually dispatching messages on the channel. Earlier in 

, only this time dispatch a message on the channel using the 

 can contain any custom properties you desire. Since many different messages are going to be broadcast on the same channel, it's a good idea to assign 

 to distinguish one kind of message from another. Set 

 because this message contains the data model for the table. 

 should contain the message you want to transmit on the channel.

Earlier, you set the column and row data on an 

 and passed that to the template with the 

const channel = new BroadcastChannel(channelName);
channel.postMessage({
  type: "data",
  detail: context,
});

If you haven't already, start up Storybook with 

Now that you're dispatching a message on the 

 callback, you should inspect the console log. Open up Dev Tools and notice nothing is logged. This is because Storybook, more accurately LitElement 

---
title: Coding Compound Components
description: You'll learn about three methods for custom elements to communicate, attribute drilling, CustomEvent, and BroadcastChannel.
isPublicLesson: true
---

## Coding Compound Components

In this section, you'll explore two ways for custom elements to communicate with one another: setting HTML attributes and sending messages over `BroadcastChannel`. First, you'll use HTML attributes to provide the channel name to both `TableCardComponent` and `TableComponent`. Currently the channel name is set on an attribute of an instance of `TableCardComponent`. You'll need to update the template of `TableCardComponent` to include an instance of `TableComponent` and pass the name of the channel using attribute drilling to `TableComponent`.

`TableComponent` is ultimately the component that requires the mock data to render columns and rows. You'll use the channel name passed through an attribute on `TableComponent` to set up `BroadcastChannel` internally and subscribe to messages broadcast on the channel. In the story file, you'll broadcast a message that contains the mock data to `TableComponent`.

## Attribute Drilling

Custom elements have robust ways to listen for changes on HTML attributes (`observedAttributes`) and react to those changes (`attributeChangedCallback`). Setting HTML attributes on a custom element is a perfectly viable way to communicate with the element, provided the element is queriable. Since `TableComponent` is a direct child of `TableCardComponent`, you can select the element with `querySelector` and use `setAttribute` to change the attribute.

To get started, update the template of `TableCardComponent` to include a `CardComponent`. `CardComponent` has several HTML template slots you can set content.

```typescript
@Component({
  selector: 'in-tablecard',
  style: css``,
  template: html`
    <in-card>
      <table is="in-table" slot="content"></table>
      <div class="table-footer" slot="footer"></div>
    </in-card>
  `,
})
```

`TableComponent` is a customized built-in element, so you can use it like any other `HTMLTableElement`. Add a `HTMLTableElement` to the inner content of the `CardComponent` and set the `slot` attribute to `content` so the table displays in the main content area of the card. Next, add a `HTMLDivElement`, give it a CSS class name set to `table-footer`, and set the `slot` attribute to `footer`. You'll use the class name later to style the footer.

Import `CardComponent` into `TableCard.stories.js` so you can use the component in the context of the story.

```javascript { actualFilename=./protected/src/TableCard.stories.js endLine=8 startLine=8 statedFilename=TableCard.stories.js url=https&#x3A;//gitlab.com/fullstackio/books/fullstack-web-components/module_08/lesson_08.03/protected/src/TableCard.stories.js#L8 }
import { CardComponent } from "./../card/Card";
```

Additionally, export `CardComponent` to satisfy Storybook's Webpack compilation.

```typescript
export { CardComponent, TableCardComponent, TableComponent, ColumnData };
```

Back in `TableCard.ts`, add the `observedAttributes` method as a static getter on `TableCardComponent` and return an `Array` with the `String` `channel` set as the only item in the `Array`. This enables the custom element to listen for changes on a HTML attribute with the name `channel`.

```typescript
static get observedAttributes() {
  return ['channel'];
}
```

To pass the value of the `TableCardComponent channel` HTML attribute to `TableComponent` you'll first need to select the instance of `TableComponent` using `querySelector`. An easy way to do this is via a getter on `TableCardComponent` named `$table`. With this method you can keep `TableComponent` strictly typed by setting the return type of the getter method to `HTMLTableElement`. Finally, return `this.shadowRoot.querySelector('table')` in the getter method. You need to query for the `HTMLTableElement` on the `shadowRoot` because `TableCardComponent` is an autonomous custom element employing Shadow DOM.

```typescript
get $table(): HTMLTableElement {
  return this.shadowRoot.querySelector('table');
}
```

In the `attributeChangedCallback` you'll reference `this.$table` to pass the value of the `channel` attribute from `TableCardComponent` to `TableComponent`. You'll also set up a new instance of `BroadcastChannel` in the `attributeChangedCallback` and store the instance on a new property of `TableCardComponent` we'll name `channel`. Set the type definition of the `channel` prior to the `constructor` in `TableCardComponent`.

```typescript
private channel: BroadcastChannel;
```

Set up the `attributeChangedCallback` method to react to changes to the value of the `channel` HTML attribute. Just like in previous chapters, use the `name` and `next` arguments of the ``attributeChangedCallback`method and a`switch`statement. In the`channel`, switch`case`, set up a`new BroadcastChannel`and pass in the value of the`channel`attribute to the first argument using`next`.`BroadcastChannel`requires a channel name, at the very least. We'll leave the`channel`here for later, in case we need to react to messages on the channel in`TableCardComponent`. Next, reference the`TableComponent`with`this.$table`and use`setAttribute`to pass the`channel`attribute value to`TableComponent\`.

```typescript
attributeChangedCallback(name, prev, next) {
  switch (name) {
    case 'channel':
      this.channel = new BroadcastChannel(next);
      this.$table.setAttribute('channel', next);
      break;
  }
}
```

In `TableComponent`, we still need a way to listen for changes to the `channel` attribute that you just set via the `attributeChangedCallback` in `TableCardComponent`. Set up a similar `observedAttributes` static getter in `Table.ts` to listen for changes on the `channel` attribute.

```typescript
static get observedAttributes() {
  return ['channel'];
}
```

Just like in `TableCardComponent`, you'll need to create an instance of `BroadcastChannel` in `TableComponent` to listen for messages on the channel. Setup a property on the `TableComponent class` type defined as `BroadcastChannel`.

```typescript
private channel: BroadcastChannel;
```

The `attributeChangedCallback` on `TableComponent` should be similar to `TableCardComponent`. Listen for changes on the `channel` attribute and set up an instance of `BroadcastChannel`. This time, call `onmessage`, a method available on the instance of `BroadcastChannel` that lets you bind a `function` and listen for messages. Set the value of `this.channel.onmessage` to a class method we haven't made yet: `this.onMessage`, making sure to call the method with `bind` otherwise the context inside `onMessage` will be the `BroadcastChannel` instead of `TableComponent`.

```typescript
attributeChangedCallback(name, prev, next) {
  switch (name) {
    case 'channel':
      this.channel = new BroadcastChannel(next);
      this.channel.onmessage = this.onMessage.bind(this);
      break;
  }
}
```

Add the `onMessage` method on `TableComponent`. `onMessage` behaves like other event listeners. Whenever a message is broadcast on the channel, an event passes through the first argument of `onMessage` since it's bound to `this.channel.onmessage`. Set up a `console.log` temporarily to easily inspect messages on `BroadcastChannel`.

```typescript
onMessage(ev) {
  console.log(ev.data);
}
```

## BroadcastChannel

So far you've set up `TableComponent` to listen for messages on `BroadcastChannel` but nothing is actually dispatching messages on the channel. Earlier in `TableCard.stories.js` you established the `channelName` that was set on the `channel` HTML attribute of `TableCardComponent`.

In `Template`, use the `channelName` to instantiate yet another instance of `BroadcastChannel`, only this time dispatch a message on the channel using the `postMessage` method, passing this method an `Object` containing two properties: `type` and `detail`. This `Object` can contain any custom properties you desire. Since many different messages are going to be broadcast on the same channel, it's a good idea to assign `type` to distinguish one kind of message from another. Set `type` to `data` because this message contains the data model for the table. `detail` should contain the message you want to transmit on the channel.

Earlier, you set the column and row data on an `Object` named `TableContext` and passed that to the template with the `context` argument. Set `detail` to the `context`.

```typescript
const channel = new BroadcastChannel(channelName);
channel.postMessage({
  type: "data",
  detail: context,
});
```

If you haven't already, start up Storybook with `yarn start`.

Now that you're dispatching a message on the `BroadcastChannel` and `TableComponent` is listening via the `this.channel.onmessage` callback, you should inspect the console log. Open up Dev Tools and notice nothing is logged. This is because Storybook, more accurately LitElement `html`, requires at least one tick of the JavaScript engine to compile the template. Wrap the call to `postMessage` in a `setTimeout` to address this behavior.

```typescript
const channel = new BroadcastChannel(channelName);
setTimeout(() => {
  channel.postMessage({
    type: "data",
    detail: context,
  });
}, 0);
```

You should now see the console log in Dev Tools.

## Rendering Columns and Rows

Messages are flowing from the story to `TableComponent` but we don't have a method to react to the message except for a `console.log` at this point. The message broadcast to `TableComponent` contains a data model for displaying columns and rows in the table. To react to this data model, replace the `console.log` in `onMessage` with a call to a yet unrealized method: `onTableData`, making sure to pass `ev.data.detail` to the new method.

```typescript
onMessage(ev) {
  switch (ev.data.type) {
    case 'data':
      this.onTableData(ev.data.detail);
      break;
  }
}
```

Declare the `onTableData` method and give it an argument. We'll call this argument `next` for lack of a better name. Rendering the header and body of the table are completely different algorithms, so split up the rendering of these table sections into two methods: `renderHeader` and `renderRows`. Pass each their respective property on the data model: `next.columnData` and `next.rowData`.

```typescript
onTableData(next) {
  this.renderHeader(next.columnData);
  this.renderRows(next.rowData);
}
```