Web Components: custom elements and their lifecycle

Useful to know

Web Components brings together browser technologies to create reusable own elements. These include custom elements, Shadow DOM and HTML templates. Each mechanism has a different task: defining its own element, encapsulating part of the structure and preparing content for reuse. They can work together, but they are not the same concept. Distinguishing them helps to choose exactly the required part, instead of making each component unnecessarily complex. [1]

Custom element is defined by JavaScript and registered for use in the document. Standard mechanisms also provide functions related to its life cycle. For example, connectedCallback is called when added to the document, and disconnectedCallback - when removed. Changes to observed attributes can be processed by attributeChangedCallback. [2] Thus the behavior is not limited to the original creation. The item can be turned on, off and updated in different parts of the life of the page.

Let's look at a fictional component for switching between two ways of viewing photos. It has initial selection, buttons and a score area. Before implementation, we can describe the input and output: how the initial mode is set and how the rest of the page understands that the choice has been changed. This is the contract of the component. The mere use of its own HTML element does not guarantee that this contract is convenient or consistent. It should be considered according to the task.

Shadow DOM allows attaching a separate DOM tree to an element and is part of the encapsulation mechanisms. [1] This is useful for the organization of a component, but does not negate the need to make it understandable on the page. In a learning example, we can indicate which parts belong to the internal implementation and which are intended to be adjusted from the outside. Thus, the team avoids random dependencies on an internal arrangement, which may change in the next edit.

Practical inspection should include more than the first display. We add the component, change a setting, remove it, and turn it back on. At each stage we record the expected selection and the reaction of the buttons. This is especially useful when the component registers listeners or supports temporary work. The goal is for an action to have one predictable result, regardless of whether the item is new or has already been used earlier on the same page.

The well-defined component has a small and clear interface: understandable attributes, described events, and verifiable states. This allows reuse without copying hidden assumptions. Web Components provides the standard mechanisms, but the sustainability of the solution comes from the boundary between the component and the remaining document. When this boundary is clear, the individual parts can be changed and tested more predictably, and the behavior remains understandable to the person using them.