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

Implementing a class decorator is going to improve the ergonomics of Web Component development quite significantly. We'll enhance the class-based implementation which custom elements rely on by cleaning up each 

, choosing to move the declaration of a HTML template and CSS to a new 

. This, combined with abstracting template and style generation to reusable 

 will have the positive effect of reducing the boilerplate for each component. For example, when you are finished with this section, 

@Component({
  custom: { extends: "button" },
  selector: "in-button",
  style: buttonStyles,
})
export class ButtonComponent extends HTMLButtonElement {
  constructor() {
    super();
  }
  connectedCallback() {
    this.classList.add("in-button");
    attachStyle(this);
  }
}

 directory of the monorepo for the first time, which currently only has one source file: 

. To keep this package organized, we should figure out a way to divide the code into logical chunks. Making a directory for all decorators seems prudent, then organizing the decorators by function.

To start developing the component decorator, create a new directory in 

packages/common/src/decorator/component.ts

mkdir -p packages/common/src/decorator
touch packages/common/src/decorator/index.ts
touch packages/common/src/decorator/component.ts

 manages exports for several files in the same directory. Other files in a directory contain library code.

First let's define the interface used by the component decorator. We'll need this 

 to keep the first argument of the decorator 

export interface ElementMeta {
  selector?: string;
  style?: string;
  template?: string;
}

. All three properties are optional, denoted by the 

. Each of these properties are optional to allow flexibility for the end-user. 

 in the context of the decorator, but what if the end-user for some reason has to register components in some other way? The user could omit the selector and register the component however they like. There are times an engineer may want to style the component, or not. Alternatively, there may be no need for a template, perhaps only styling. Making each property optional allows for flexibility, but as we'll observe programmatically, we'll have to check each property on 

TypeScript class decorators are factory functions, that is, they return a 

 definition of the component using this decorator. Based on the values of properties on the 

 so we can use those properties to register the component with the 

 and instantiate a HTML template with Shadow DOM.

 keyword. Name the first argument of the 

 and type define the argument with the interface you just created: 

 that is being decorated. Inside this factory 

 will use the decorator. It would be difficult to implement type safety here, nor should we.

export function Component(meta: ElementMeta) {
  return (target: any) => {
    return target;
  };
}

 is returned is the most interesting part of the class decorator. Before we start modifying the class definition, let's put a fail-safe mechanism in for users who haven't specified an 

export function Component(meta: ElementMeta) {
  if (!meta) {
    console.error("Component must include ElementMeta to compile");
    return;
  }

 and when truthy, displays a console error for developers in Dev Tools, then aborts the rest of the algorithm that depends on 

We have two objectives for the class decorator: register the component using the 

 definition to later append a HTML template to Shadow DOM using the 

Let's start with registering the component via the decorator function. In the factory function, reference the 

 and pass it and the class definition, here named 

export function Component(meta: ElementMeta) {
  if (!meta) {
    console.error("Component must include ElementMeta to compile");
    return;
  }
  return (target: any) => {
    customElements.define(meta.selector, target);
    return target;
  };
}

This one line allows the end-user to omit a call from 

 in their implementation, as you'll later observe when refactoring 

if (meta.selector) {
  customElements.define(meta.selector, target);
}

That was easy enough, although we're not yet using the class decorator for its main function: modifying the 

 it decorates. This just happens to be a convenient place to also make the call to 

 and create a HTML template, then append it to the 

 like we've done in previous chapters, because the class decorator doesn't have access to the instance of the class, only the definition.

Class decorators are a place where you can modify the 

, so that's exactly what we're going to do. We're going to store the 

, here is a good place for some conditionals that set both of these properties to empty 

if (!meta.style) {
  meta.style = "";
}
if (!meta.template) {
  meta.template = "";
}

export function Component(meta: ElementMeta) {
  if (!meta) {
    console.error("Component must include ElementMeta to compile");
    return;
  }
  return (target: any) => {
    if (!meta.style) {
      meta.style = "";
    }
    if (!meta.template) {
      meta.template = "";
    }
    target.prototype.elementMeta = meta;
    if (meta.selector) {
      customElements.define(meta.selector, target);
    }
    return target;
  };
}

 decorator is finished, but you still need to provide the decorator and possibly the 

. In previous chapters you developed components in a sibling directory at 

 decorator from the files in that package, you need to properly 

To finalize development of the decorator, add the proper exports to

export { Component } from "./component";
export type { ElementMeta } from "./component";

---
title: Class Decorator
description: How to code an interface for Web Components with TypeScript decorators that enables declaration of the selector, styles, and template.
isPublicLesson: true
---

## Class Decorator

Implementing a class decorator is going to improve the ergonomics of Web Component development quite significantly. We'll enhance the class-based implementation which custom elements rely on by cleaning up each `constructor`, choosing to move the declaration of a HTML template and CSS to a new `function` that decorates the `class`. This, combined with abstracting template and style generation to reusable `function` will have the positive effect of reducing the boilerplate for each component. For example, when you are finished with this section, `ButtonComponent` will look something like this.

```typescript
@Component({
  custom: { extends: "button" },
  selector: "in-button",
  style: buttonStyles,
})
export class ButtonComponent extends HTMLButtonElement {
  constructor() {
    super();
  }
  connectedCallback() {
    this.classList.add("in-button");
    attachStyle(this);
  }
}
```

We're working in the `packages/common` directory of the monorepo for the first time, which currently only has one source file: `index.ts`. To keep this package organized, we should figure out a way to divide the code into logical chunks. Making a directory for all decorators seems prudent, then organizing the decorators by function.

To start developing the component decorator, create a new directory in `packages/common/src/decorator`, then make a new file at `packages/common/src/decorator/index.ts`, and another file at `packages/common/src/decorator/component.ts`.

```bash
mkdir -p packages/common/src/decorator
touch packages/common/src/decorator/index.ts
touch packages/common/src/decorator/component.ts
```

Any file named `index.ts` manages exports for several files in the same directory. Other files in a directory contain library code.

Open `packages/common/src/decorator/component.ts` in your IDE to begin.

### Define the Interface

First let's define the interface used by the component decorator. We'll need this `interface` to keep the first argument of the decorator `function` type safe. Declare a new `interface` named `ElementMeta` and ensure it is exported with the `export` keyword.

```javascript { actualFilename=./protected/src/component.ts endLine=5 startLine=1 statedFilename=component.ts url=https&#x3A;//gitlab.com/fullstackio/books/fullstack-web-components/module_07/lesson_07.02/protected/src/component.ts }
export interface ElementMeta {
  selector?: string;
  style?: string;
  template?: string;
}
```

There are three properties on this `interface` we should define: `selector`, `style`, and `template`. All three properties are optional, denoted by the `?` prior to `:`. Each of these properties are optional to allow flexibility for the end-user. `selector` will be used to automatically call `customElements.define` in the context of the decorator, but what if the end-user for some reason has to register components in some other way? The user could omit the selector and register the component however they like. There are times an engineer may want to style the component, or not. Alternatively, there may be no need for a template, perhaps only styling. Making each property optional allows for flexibility, but as we'll observe programmatically, we'll have to check each property on `ElementMeta` exists and react accordingly.

### Component Decorator

TypeScript class decorators are factory functions, that is, they return a `function` that constructs an `Object`. The `Object` we're concerned with is the `class` definition of the component using this decorator. Based on the values of properties on the `ElementMeta`, we want to modify the `prototype` of the `class` so we can use those properties to register the component with the `CustomElementRegistry` and instantiate a HTML template with Shadow DOM.

The basic structure of the `function` is as follows: Declare a new `function` named `Component` and make sure it's exportable with the `export` keyword. Name the first argument of the `function` `meta` and type define the argument with the interface you just created: `ElementMeta`. return a `function`. The first argument of this `function` is defined by TypeScript when you use `Component` in the context of a class decorator. `target` is the class definition of the `class` that is being decorated. Inside this factory `function`, return the class definition. `target` should be type defined as `any` here because so many different `class` will use the decorator. It would be difficult to implement type safety here, nor should we.

```typescript
export function Component(meta: ElementMeta) {
  return (target: any) => {
    return target;
  };
}
```

What happens before the `target` is returned is the most interesting part of the class decorator. Before we start modifying the class definition, let's put a fail-safe mechanism in for users who haven't specified an `ElementMeta` in the first argument of `Component`.

```javascript { actualFilename=./protected/src/component.ts endLine=11 startLine=7 statedFilename=component.ts url=https&#x3A;//gitlab.com/fullstackio/books/fullstack-web-components/module_07/lesson_07.02/protected/src/component.ts#L7 }
export function Component(meta: ElementMeta) {
  if (!meta) {
    console.error("Component must include ElementMeta to compile");
    return;
  }
```

The above conditional checks if `meta` is `undefined` and when truthy, displays a console error for developers in Dev Tools, then aborts the rest of the algorithm that depends on `ElementMeta`.

We have two objectives for the class decorator: register the component using the `selector` property, then add metadata on the `class` definition to later append a HTML template to Shadow DOM using the `style` and `template` properties on the `ElementMeta`.

Let's start with registering the component via the decorator function. In the factory function, reference the `selector` and pass it and the class definition, here named `target`, to `customElements.define`.

```typescript
export function Component(meta: ElementMeta) {
  if (!meta) {
    console.error("Component must include ElementMeta to compile");
    return;
  }
  return (target: any) => {
    customElements.define(meta.selector, target);
    return target;
  };
}
```

This one line allows the end-user to omit a call from `customElements.define` in their implementation, as you'll later observe when refactoring `TextInputComponent`, `ButtonComponent`, and `CardComponent`, but the user has the option to ignore `selector` entirely in the `ElementMeta`, so be sure to wrap the call to `define` in a conditional.

```typescript
if (meta.selector) {
  customElements.define(meta.selector, target);
}
```

That was easy enough, although we're not yet using the class decorator for its main function: modifying the `prototype` of the `class` it decorates. This just happens to be a convenient place to also make the call to `customElements.define`. We can't use this space to call `attachShadow` and create a HTML template, then append it to the `shadowRoot` like we've done in previous chapters, because the class decorator doesn't have access to the instance of the class, only the definition.

Class decorators are a place where you can modify the `prototype` of a `class`, so that's exactly what we're going to do. We're going to store the `ElementMeta` passed through the `Component function` arguments on the `prototype` of the `class`, so we can later access the `template` and `style` in the `constructor` of the component `class`.

Set a new property called `elementMeta` on the `prototype` to the `meta` that was passed into the `Component function`.

```typescript
target.prototype.elementMeta = meta;
```

If we want to avoid the `style` and `template` properties from ever being `undefined`, here is a good place for some conditionals that set both of these properties to empty `string` in the case they are `undefined`.

```typescript
if (!meta.style) {
  meta.style = "";
}
if (!meta.template) {
  meta.template = "";
}
```

When you are finished with the `Component` decorator, the `function` should look like this:

```javascript { actualFilename=./protected/src/component.ts endLine=25 startLine=7 statedFilename=component.ts url=https&#x3A;//gitlab.com/fullstackio/books/fullstack-web-components/module_07/lesson_07.02/protected/src/component.ts#L7 }
export function Component(meta: ElementMeta) {
  if (!meta) {
    console.error("Component must include ElementMeta to compile");
    return;
  }
  return (target: any) => {
    if (!meta.style) {
      meta.style = "";
    }
    if (!meta.template) {
      meta.template = "";
    }
    target.prototype.elementMeta = meta;
    if (meta.selector) {
      customElements.define(meta.selector, target);
    }
    return target;
  };
}
```

### Build the `@in/common` package

Development of the `Component` decorator is finished, but you still need to provide the decorator and possibly the `interface` for use outside of the `@in/common package`. In previous chapters you developed components in a sibling directory at `packages/component`. To access the `Component` decorator from the files in that package, you need to properly `export` from the `@in/common` package.

To finalize development of the decorator, add the proper exports to
`packages/common/src/decorator/index.ts` and `packages/common/index.ts`.

In `packages/common/src/decorator/index.ts` add the following exports.

```typescript
export { Component } from "./component";
export type { ElementMeta } from "./component";
```

Export the same from `packages/common/index.ts`.

```typescript
export { Component } from "./src/decorator";
export type { ElementMeta } from "./src/decorator";
```

`index.ts` is the entry point of the `@in/common` package. When the `@in/common` package is built, other packages in the monorepo will be able to reference anything exported from the `index.ts`.

Check the build successfully runs, which means your TypeScript is valid. This is your first time running the `build` command because previously you didn't really need to. Storybook was handling the development environment for all the components so far. In future chapters you'll need to build the `@in/ui` package as well, but for now you'll need to make sure the `@in/common` package is built using the following command.

```bash
lerna exec --scope @in/common -- yarn build
```

If you get an error like `zsh: command not found: lerna` make sure lerna is installed globally and try the build command again.

```bash
npm install --global lerna
```

If you see `lerna success` output in the Terminal, you are ready to proceed. Otherwise, check your TypeScript is correct.

### Abstracting attachShadow

Now that we have `ElementMeta` stored on the `prototype` of any `class` using the `Component` decorator, we can write a reusable `function` that could be used in the `constructor` of the same `class` to instantiate Shadow DOM much like we already did in the components developed in Part One. By abstracting this logic to a reusable `function` we can reduce several lines of code in each component implementation down to one line.

Basically we want to take something like this...

```typescript
const shadowRoot = this.attachShadow(options);
const template = document.createElement("template");
template.innerHTML = `
    <style>
      :host {
        display: block;
        background: var(--color-white);
        border-radius: var(--radius-md);
        box-shadow: var(--shadow);
        overflow: hidden;
        max-width: 320px;
      }     
    </style>
    <div class="container"></div>
    `;
shadowRoot.appendChild(template.content.cloneNode(true));
```

and reduce it to one line.

```typescript
attachShadow(this, options);
```

The first argument of `attachShadow` is the instance of the `class` which in the `constructor` you can reference as `this`. The second argument is the `Object` that configures the call to `element.attachShadow`. According to [MDN](https://developer.mozilla.org/en-US/docs/Web/API/Element/attachShadow), this `Object` can accept three fields: `mode` and `delegatesFocus`. The type definition exported from TypeScript's [lib.dom.d.ts](https://github.com/microsoft/TypeScript/blob/97a7901f26290a13ea6c3b057c8720c1614cb221/lib/lib.dom.d.ts#L1610) called `ShadowRootInit` reveals a third field: `slotAssignment`. You've set the fields on this `Object` in prior chapters for `TextInputComponent`, `ButtonComponent`, and `CardComponent`.

To start development of this new `function`, make a new directory named template in `packages/common/src` and create a new file in that directory named `index.ts`. Create another file in the directory named `shadow.ts`.

```typescript
mkdir packages/common/src/template
touch packages/common/src/template/index.ts
touch packages/common/src/template/shadow.ts
```

In `packages/common/src/template/shadow.ts`, create a new `function` named `attachShadow` and `export` it from the file. Declare two arguments for `attachShadow`: `context` and `options`, making `options` optional with `?` and type defining `context` as `any` for now and `options` as `ShadowRootInit`, a type definition exported from lib.dom.d.ts.

```typescript
export function attachShadow(context: any, options?: ShadowRootInit) {}
```

Follow up in `packages/common/src/template/index.ts` and ensure `attachShadow` is exported for the main `index.ts`.

```typescript
export { attachShadow } from "./shadow";
```

Finally in `packages/common/index.ts` export the `attachShadow function`.

```typescript
export { attachShadow } from "./src/template";
```

Jumping back to `packages/common/src/template/shadow.ts`, fill in the algorithm for `attachShadow`, referencing the `constructor` in `CardComponent` at `packages/component/src/card/Card.ts` as a guide. Make a `const` named `shadowRoot`, type defined as `ShadowRoot`, equal to `context.attachShadow`. Since we've opted to make `options` optional, we need to at the very least give `context.attachShadow` the minimum `ShadowRootInit`, which requires `mode`.

```typescript
const shadowRoot: ShadowRoot = context.attachShadow(
  options || { mode: "open" }
);
```

On the next line, make a `const` named `template` equal to `document.createElement('template')`. This line creates a new HTML template.

```typescript
const template = document.createElement("template");
```

Set the content of the HTML template using the `ElementMeta` stored on the `prototype` of whatever `class` will use this `attachShadow function`. Pass in `context.elementMeta.style` to a `<style>` tag and `context.elementMeta.template` afterward.

```typescript
template.innerHTML = `<style>${context.elementMeta.style}</style>${context.elementMeta.template}`;
```

Finally, append a clone of the HTML template to the `ShadowRoot`.

```typescript
shadowRoot.appendChild(template.content.cloneNode(true));
```

When you are finished, the `attachShadow function` should look like this:

```javascript { actualFilename=./protected/src/template.ts endLine=8 startLine=1 statedFilename=shadow.ts url=https&#x3A;//gitlab.com/fullstackio/books/fullstack-web-components/module_07/lesson_07.02/protected/src/template.ts }
export function attachShadow(context: any, options?: ShadowRootInit) {
  const shadowRoot: ShadowRoot = context.attachShadow(
    options || { mode: "open" }
  );
  const template = document.createElement("template");
  template.innerHTML = `<style>${context.elementMeta.style}</style>${context.elementMeta.template}`;
  shadowRoot.appendChild(template.content.cloneNode(true));
}
```

With `Component` and `attachShadow` now supporting autonomous and form-associated custom elements, you can now refactor `CardComponent` and `TextInputComponent` to use the new decorator pattern. Build the `@in/common` package again so files inside the `@in/ui` package can pickup the latest changes.

```bash
lerna exec --scope @in/common -- yarn build
```

### Refactor CardComponent and TextInputComponent

Open `packages/component/src/card/Card.ts` and observe the current state of the `CardComponent class`. Before you replace the content in the `constructor`, import `Component` and `attachShadow` from `@in/common`.

```typescript
import { Component, attachShadow } from "@in/common";
```

Add the `Component` decorator to `CardComponent`.

```typescript
@Component({

})
export class CardComponent extends HTMLElement {
```

Remove the line at the bottom of the file that registers the component, noting the tag name `in-card`.

Remove `customElements.define('in-card', CardComponent);`.

Set the `selector` property to the `ElementMeta` passed into `Component` to `in-card`, the same `string` originally used to register the component.

```typescript
@Component({
  selector: 'in-card',
})
```

Carefully move the content of the `<style>` tag in the `constructor` to the new `style` property on `ElementMeta`.

```typescript
@Component({
  selector: 'in-card',
  style: `
  :host {
    display: block;
    background: var(--color-white);
    border-radius: var(--radius-md);
    box-shadow: var(--shadow);
    overflow: hidden;
    max-width: 320px;
  }
  ::slotted(*) {
    padding-left: var(--padding-lg);
    padding-right: var(--padding-lg);
  }
  ::slotted(a:link), ::slotted(a:visited) {
    display: block;
  }
  ::slotted(:last-child) {
    padding-bottom: var(--margin-lg);
  }
  ::slotted(img) {
    width: 100%;
    padding-left: 0px;
    padding-right: 0px;
  }
  `,
})
```