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

 the various modes required by the acceptance criteria: read-only and editable, while also giving the user the ability to add and delete rows. You'll further practice a separation of concerns by developing two new components: 

 that handle the functionality of a row and cell, respectively.

 in the previous section to communicate between components in the same layout. We'll add 

 as a method for custom element communication in this section. You'll also learn how to dynamically create new instances of customized built-in elements with 

 and give custom elements data with HTML data attributes.

In the last section, you dynamically created 

 in response to receiving a message over 

. To further promote a separation of concerns, let's break out these two elements into new components. Otherwise, logic that should probably be contained by the 

 will be customized built-in elements because we want them to retain the characteristics of the native DOM elements, while enhancing the element with more functionality. 

 will manage state for the entire row, while 

, whether it's in "edit mode" or "read-only mode", and set the value of the cell.

To start, make a new file in the same directory named 

. This file will contain the component logic for 

 in your IDE and begin developing the component by importing the 

export class TrComponent extends HTMLTableRowElement {
  constructor() {
    super();
  }
}

 decorator to set the custom element tag name as 

, making sure to also provide the necessary 

 property needed to register customized built-in elements.

@Component({
  selector: 'in-tr',
  custom: { extends: 'tr' },
})

 for the Storybook Webpack configuration.

export {
  CardComponent,
  TableCardComponent,
  TableComponent,
  TrComponent,
  ColumnData,
};

 the same way. Start by making a new file named 

. You'll need to style parts of a custom template in 

import { Component, attachTemplate, attachStyle, html, css } from "@in/common";

export class TdComponent extends HTMLTableCellElement {
  constructor() {
    super();
    attachTemplate(this);
    attachStyle(this);
  }
}

 for registering the customized built-in element with the 

@Component({
  selector: 'in-td',
  custom: { extends: 'td' },
  style: css`

  `,
  template: html`

  `,
})
export class TdComponent extends HTMLTableCellElement {

 should display two modes: read-only and editable. In read-only mode, each 

 should display non-editable read-only text, while in edit mode the component should display a text input, more specifically 

 to the template, tagging each with a unique CSS class name. In the span classed 

template: html`
 
 
 <in-texinput type="text"></in-texinput>
 
 `,

import { TextInputComponent } from "../input/TextInput";

 to satisfy Storybook's Webpack compilation.

export {
  CardComponent,
  TableCardComponent,
  TableComponent,
  TrComponent,
  TdComponent,
  TextInputComponent,
  ColumnData,
};

 you introduced in the template. We need to ensure the read-only content is styled per the spec in Figma, while also retaining the characteristics of a 

. To hide/show the read-only value, let's use a similar method to the buttons in 

 HTML attribute is truthy. The element should be 

style: css`
  .td-readonly {
    display: table-cell;
    box-sizing: border-box;
    margin-top: var(--margin-xs);
    padding-left: var(--padding-sm);
    height: 44px;
    vertical-align: middle;
  }
  .td-readonly[hidden='true'] {
    display: none;
  }
`,

Add getters for each of the elements you introduced to the layout: both 

. You'll need to reference each of these elements in the component logic you'll develop in 

  get $readOnly(): HTMLSpanElement {
    return this.querySelector('.td-readonly');
  }

  get $input(): HTMLInputElement {
    return this.querySelector('in-texinput');
  }

  get $inputContainer(): HTMLSpanElement {
    return this.querySelector('.td-input');
  }

setValue(value: string) {
  this.$readOnly.innerText = value;
}

 to communicate the value of the cell to 

 it seems appropriate to set the value via a HTML attribute. Listen for changes to a 

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

attributeChangedCallback(name, prev, next) {
  switch (name) {
    case 'value':
      this.setValue(next);
      break;
  }
}

We'll require another method for toggling the mode of the 

 from read-only to editable. Declare a method named 

 statement. Depending on the truthiness of 

setMode(readOnly: boolean) {
  if (readOnly) {
    this.$readOnly.removeAttribute('hidden');
    this.$inputContainer.setAttribute('hidden', 'true');
  } else {
    this.$readOnly.setAttribute('hidden', 'true');
    this.$inputContainer.removeAttribute('hidden');
  }
}

, we need to coerce the value of the attribute to a boolean because 

---
title: Making the Table Editable
description: You'll learn about how to create a separation of concerns between the many custom elements that comprise the editable table.
isPublicLesson: true
---

## Making the Table Editable

In this section, you'll work on giving `TableComponent` the various modes required by the acceptance criteria: read-only and editable, while also giving the user the ability to add and delete rows. You'll further practice a separation of concerns by developing two new components: `TrComponent` and `TdComponent` that handle the functionality of a row and cell, respectively.

We used attribute drilling and `BroadcastChannel` in the previous section to communicate between components in the same layout. We'll add `CustomEvent` as a method for custom element communication in this section. You'll also learn how to dynamically create new instances of customized built-in elements with `createElement` and give custom elements data with HTML data attributes.

### Separation of Concerns

In the last section, you dynamically created `HTMLTableRowElement` and `HTMLTableCellElement` in `TableComponent` in response to receiving a message over `BroadcastChannel`. To further promote a separation of concerns, let's break out these two elements into new components. Otherwise, logic that should probably be contained by the `HTMLTableCellElement` will be leaking all over `TableComponent`. `TrComponent` and `TdComponent` will be customized built-in elements because we want them to retain the characteristics of the native DOM elements, while enhancing the element with more functionality. `TrComponent` will manage state for the entire row, while `TdComponent` will manage the view of the `HTMLTableCellElement`, whether it's in "edit mode" or "read-only mode", and set the value of the cell.

To start, make a new file in the same directory named `Tr.ts`. This file will contain the component logic for `TrComponent`.

```bash
touch packages/component/src/table/Tr.ts
```

Open `Tr.ts` in your IDE and begin developing the component by importing the `Component` decorator from `@in/common`.

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

Declare a new `class` named `TrComponent` and have it extend `HTMLTableRowElement`. Make the `constructor` and insert a call to `super()`. Ensure the `class` is exported using the `export` keyword.

```typescript
export class TrComponent extends HTMLTableRowElement {
 constructor() {
 super();
 }
}
```

Use the `Component` decorator to set the custom element tag name as `in-tr`, making sure to also provide the necessary `custom` property needed to register customized built-in elements.

```typescript
@Component({
 selector: 'in-tr',
 custom: { extends: 'tr' },
})
```

In `TableCard.stories.js` import `TrComponent` from `Tr.ts`.

```typescript
import { TrComponent } from "./Tr";
```

Export `TrComponent` for the Storybook Webpack configuration.

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

Set up `TrComponent` the same way. Start by making a new file named `Td.ts` in the same directory.

```bash
touch packages/component/src/table/Td.ts
```

Import all the necessary API from `@in/common`. You'll need to style parts of a custom template in `TdComponent` so be sure to import `attachTemplate` and `attachStyle` in addition to `Component`.

```typescript
import { Component, attachTemplate, attachStyle, html, css } from "@in/common";
```

Export a class named `TrComponent` that extends `HTMLTableCellElement`. Call `super()` in the `class constructor` as well as `attachTemplate` and `attachStyle`.

```typescript
export class TdComponent extends HTMLTableCellElement {
 constructor() {
 super();
 attachTemplate(this);
 attachStyle(this);
 }
}
```

Set up the `Component` decorator, passing in the tag name as `in-td` to the `selector` property, the appropriate `Object` for registering the customized built-in element with the `CustomElementRegistry`. Leave the `style` and `template` properties blank for now.

```typescript
@Component({
 selector: 'in-td',
 custom: { extends: 'td' },
 style: css`

 `,
 template: html`

 `,
})
export class TdComponent extends HTMLTableCellElement {
```

`TableComponent` should display two modes: read-only and editable. In read-only mode, each `TdComponent` should display non-editable read-only text, while in edit mode the component should display a text input, more specifically `TextInputComponent`. Add two `HTMLSpanElement` to the template, tagging each with a unique CSS class name. In the span classed `td-input`, add an instance of `TextInputComponent`.

```typescript
 template: html`
 
 
 <in-texinput type="text"></in-texinput>
 
 `,
```

Before proceeding with styling `TdComponent`, head back on over to `TableCard.stories.js` and import `TextInputComponent` into the file.

```typescript
import { TextInputComponent } from "../input/TextInput";
```

Export `TextInputComponent` from `TableCard.stories.js` to satisfy Storybook's Webpack compilation.

```typescript
export {
 CardComponent,
 TableCardComponent,
 TableComponent,
 TrComponent,
 TdComponent,
 TextInputComponent,
 ColumnData,
};
```

Moving back to `TdComponent`, add styling for both the `HTMLSpanElement` you introduced in the template. We need to ensure the read-only content is styled per the spec in Figma, while also retaining the characteristics of a `HTMLTableCellElement`. To hide/show the read-only value, let's use a similar method to the buttons in `TableCardComponent`. Add a style for when the `hidden` HTML attribute is truthy. The element should be `display: none`.

```typescript
style: css`
 .td-readonly {
 display: table-cell;
 box-sizing: border-box;
 margin-top: var(--margin-xs);
 padding-left: var(--padding-sm);
 height: 44px;
 vertical-align: middle;
 }
 .td-readonly[hidden='true'] {
 display: none;
 }
`,
```

Add getters for each of the elements you introduced to the layout: both `HTMLSpanElement` and the `TextInputComponent`. You'll need to reference each of these elements in the component logic you'll develop in `TdComponent`.

```typescript
 get $readOnly(): HTMLSpanElement {
 return this.querySelector('.td-readonly');
 }

 get $input(): HTMLInputElement {
 return this.querySelector('in-texinput');
 }

 get $inputContainer(): HTMLSpanElement {
 return this.querySelector('.td-input');
 }
```

Make another method on `TdComponent` for setting the value of the read-only `HTMLSpanElement`. Pass an argument named `value` through the method and set `value` on the `innerText` of the `HTMLSpanElement`.

```typescript
setValue(value: string) {
 this.$readOnly.innerText = value;
}
```

You'll need a way for `TableComponent` to communicate the value of the cell to `TdComponent`. Since you're already looping over `HTMLTableCellElement` in the context of `TableComponent` it seems appropriate to set the value via a HTML attribute. Listen for changes to a `value` attribute in `TdComponent` with the `observedAttributes` static getter.

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

Declare the `attributeChangedCallback` method. While using a `switch` statement, watch for the `case` of `value` and call `setValue` there.

```typescript
attributeChangedCallback(name, prev, next) {
 switch (name) {
 case 'value':
 this.setValue(next);
 break;
 }
}
```

We'll require another method for toggling the mode of the `TdComponent` from read-only to editable. Declare a method named `setMode` and pass an argument named `readOnly`, type defined as `boolean`, to an `if` statement. Depending on the truthiness of `readOnly`, hide or show the appropriate `HTMLSpanElement`.

```typescript
setMode(readOnly: boolean) {
 if (readOnly) {
 this.$readOnly.removeAttribute('hidden');
 this.$inputContainer.setAttribute('hidden', 'true');
 } else {
 this.$readOnly.setAttribute('hidden', 'true');
 this.$inputContainer.removeAttribute('hidden');
 }
}
```

Add `readonly` to the `Array` of `observedAttributes` and make a new `case` in the `attributeChangedCallback`, being sure to call `setMode` with the value of the `readonly` attribute. Since HTML attributes are `String`, we need to coerce the value of the attribute to a boolean because `setMode` expects a `boolean`. You can do this with the expression `next === 'true'`, which will return a `boolean` that is truthy, otherwise falsy.

```typescript
static get observedAttributes() {
 return ['value', 'readonly'];
}

attributeChangedCallback(name, prev, next) {
 switch (name) {
 case 'value':
 this.setValue(next);
 break;
 case 'readonly':
 this.setMode(next === 'true');
 break;
 }
}
```

`TdComponent` is now set up to render different user interfaces based on the mode passed through the `readonly` HTML attribute. However; we still need to refactor `TableComponent` to accommodate the new customized built-in elements.

### Rendering Modes

In the last section, we dynamically created `HTMLTableRowElement` and `HTMLTableCellElement` with `createElement` in the `renderRows` method in `TableComponent`. Since then, we made these elements customized built-in elements and need to update the logic in `renderRows` to accommodate the change. `createElement` takes a second argument, an `Object` that specifies for the browser that these should be instances of a customized built-in element with a tag name set on the `is` property.

Update the calls to `createElement` in `renderRows` to create customized built-in elements with the tag names you declared earlier in this section.

```typescript
const tr = document.createElement("tr", { is: "in-tr" });
```

```typescript
const td = document.createElement("td", { is: "in-td" });
```

The initial state of each table cell should be read-only as opposed to edit mode, so ensure each `TdComponent` has a call to `setAttribute` that sets the `readonly` HTML attribute to `true` on initial render.

```typescript
td.setAttribute("value", rowData[colData.property]);
td.setAttribute("readonly", "true");
```

### Using CustomEvent to Transmit Row Data

Thus far we haven't done much with `TrComponent`, even though the purpose of this component is to store row state. `TrComponent` is a direct descendant of `TableComponent` and in the `renderRows` method we already have a reference to each `TrComponent`. One of the requirements for using `CustomEvent` is being able to easily select the element. The main reason we've stuck with `BroadcastChannel` is because the deeply nested elements that required events were not immediately queriable from higher up in DOM. Even then, we needed to use attribute drilling so the nested `TableComponent` could listen to the same channel. Although this only required passing a `String` through HTML attributes and not a complex `Object` or `Array`. `CustomEvent` can be a viable means for component communication, especially when complex data has to be transmitted.

The `Object` that corresponds to each row in the loop is `rowData`. Use the `dispatchEvent` on `HTMLElement` to send a `new CustomEvent` named `data`, passing in `rowData` in the `detail` property.

```typescript
tr.dispatchEvent(
 new CustomEvent("data", {
 detail: rowData,
 })
);
```

Let's react to this `CustomEvent` in `TrComponent` before providing a method that displays each mode in `TableComponent`. In `Tr.ts`, add a new `public` property on the `class` called `$rowData`. This property should be publicly accessible so `TableComponent` can access it.

```typescript
public $rowData: any;
```

Import `Listen` from `@in/common` to set up a new event listener.

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

In `TableComponent`, you dispatched a `CustomEvent` to the instance of `TrComponent`, so let's declare a new event listener with `Listen`. Declare a new method named `setValue` that serves as the event listener callback method. Pass the event through the first argument `ev` and set the value of `this.$rowData` to the `detail`.

```typescript
@Listen('data')
setValue(ev: CustomEvent) {
 this.$rowData = ev.detail;
}
```

We'll circle back to `TrComponent` later, but for now, let's stick with managing the rendering of nodes in `TableComponent`. Make a new method on `TableComponent` named `onReadOnly`. the purpose of this method is to display the `TdComponent` in read-only mode. When the method is called, select all the cells with `querySelectorAll` and loop over the `NodeList` with `forEach`. On every iteration of the loop, set the `readonly` HTML attribute of each `TdComponent` to `true`.

```typescript
onReadOnly() {
 const cells = this.querySelectorAll('td');
 cells.forEach((td) => {
 td.setAttribute('readonly', 'true');
 });
}
```

### Table Modes and State

Read-only mode was fairly trivial. To set the display of each `TdComponent`, all you had to do was set the `readonly` HTML attribute. Edit mode is a bit more complex. After the user initiates edit mode by pressing the edit button, they have the option of editing each cell or canceling the edits they made. We need a way to store the state of the rows in the table when the user enters edit mode, in the event the user wants to revert the changes. This is why we went to the trouble of storing the data for each row on `TrComponent`, but we still need a way to store the state of all rows in the context of `TableComponent`. To get started, import `TrComponent` into `Table.ts` because you'll need to reference the `$rowData` property that exists on each instance of `TrComponent` in upcoming logic.

```typescript
import { TrComponent } from "./Tr";
```

Declare a getter method on `TableComponent` that queries for all `TrComponent` in the `TableBodyElement` using `querySelectorAll`. We don't need an `Array` of `TrComponent`, but instead an `Array` of row data, so we need to use a method on `Array.prototype` not available to us on the `NodeList`. To access `map` on a `NodeList` you have to coerce the `NodeList` into an `Array` using `Array.prototype.from`.

```typescript
get state() {
 return Array.from(this.querySelector('tbody').querySelectorAll('tr')).map(
 (tr: TrComponent) => tr.$rowData
 );
}
```

Add a new `private` method on `TableComponent` named `savedState`. We'll use this property to store the state of the rows when the user enters edit mode.

```typescript
private savedState: any[];
```

Declare another method on `TableComponent` named `onEdit`. This method will handle the display of elements in edit mode and changes to row state. In `onEdit` check if `this.savedState` exists and if truthy, set `this.savedState` to the `Array` returned from the `this.state` getter. Wrap the `Array` in a call to `JSON.parse(JSON.stringify())` to copy the `Array` and make it ready to dispatch the saved state in a `CustomEvent` or message on `BroadcastChannel` if necessary.

```typescript
onEdit() {
 if (!this.savedState) {
 this.savedState = JSON.parse(JSON.stringify(this.state));
 }
}
```

Update the `onReadOnly` method to check for `this.savedState` and if truthy, call `renderRows` with the data model stored in `savedState`, then reset `savedState`, making it equal to `undefined` for the event. If the user enters edit mode once again, the check for `savedState` in `onEdit` can execute as expected.

```typescript
 onReadOnly() {
 const cells = this.querySelectorAll('td');
 cells.forEach((td) => {
 td.setAttribute('readonly', 'true');
 });
 if (this.savedState) {
 this.renderRows(this.savedState);
 this.savedState = undefined;
 }
}
```

### Orchestrating Edit Mode

The acceptance criteria for the editable table suggests that users should be able to edit each cell in the table and either save or cancel the edit. We've chosen to create a separation of concerns where needed, placing row state on instances of `TrComponent`, the display state for each cell on `TdComponent`, and the overall rendering of rows and cells on `TableComponent`. This separation of concerns begins to break down when considering the complexity of edit mode. Some concerns regarding edit mode are below.

- When a user edits a field and moves on to another input, row state should be updated
- Upon using the keyboard to navigate, users should expect to use the `Tab` key to focus the next logical cell, i.e. when focused on the last cell of a row and the user presses `Tab`, focus should flow to the first cell of the next row or the buttons in the footer.

These user experience enhancements require some binding of event listeners on the `TextInputComponent` embedded in `TdComponent`. Some may argue that this is the concern of `TdComponent` so any event listener logic should be declared in the context of `TdComponent`. Another argument for handling this logic in `TableComponent` is that `TableComponent` is responsible for rendering of nodes and should track which nodes are currently being edited as well as rendered. For the sake of development, we'll take this stance, relegating `TdComponent` to merely being concerned with view logic, while `TableComponent` is responsible for tracking not only which rows and cells are rendered, but are also being edited. For this purpose, let's add a new property on `TableComponent` named `editIndex` and type define that property as `number`, then set the initial value to `0`; the index of the first cell in the table.