Making Web Components for Different Contexts

This article is not about how to build web components, Caleb Williams has recently written a detailed guide. Let's discuss how to use them, what factors need to be considered when building, and how to effectively utilize them in your project.

If you are new to web components, Caleb's guide is well worth reading, but here are some resources that can help you get started quickly:

• Web Components – The "correct" approach
• Shadow DOM v1: Self-contained Web Components
• Web Components on MDN
• Awesome Web Components
• Recommended open web components

With web components now widely supported (thanks to the hard work of many behind the scenes) and considering that Edge will soon switch to the Chromium platform – people now see web components as a “native” and platform-compatible way to build reusable UI components to maintain consistency between design systems and web projects while leveraging the power of Shadow DOM to encapsulate styles and logic in the component itself.

This is both right and wrong. But first, let's take a look at the abstract layer triangle .

Abstract layer triangle

Technically, we should consider Web components as an extension of our favorite markup language HTML (yes!). The Web Component API allows us to create custom HTML elements that do not exist in HTML (for example<foo-bar></foo-bar> ).

Some say that web components are basically new HTML elements, so we should consider them as part of the HTML specification, so we should follow its paradigm, core concepts, and usage. If we assume all these points, we will find that our components will exist at the lowest level of the Web platform stack, side by side with HTML, CSS, and JavaScript. Frameworks and libraries (such as React, Vue, Angular, SvelteJS) work on their abstraction layer and sit on top of other tools that are in some kind of "middle-earth" such as StencilJs, Hybrids, and Lit. Beneath these abstraction layers, we can find our basic web technologies…and native web components. We can use the ALT ( Abstraction La ayer T riangle) diagram to represent this concept:

Why is this important? It helps us visualize the layers that exist on top of native components and understand their usage environment so that they can be built against the intended environment. What is the environment? That's our goal.

Same technology, different environments

Shadow DOM is a key factor in the Web Component API. It allows us to bundle JavaScript and CSS into custom elements to prevent external interference and style operations unless we explicitly allow it. Developers can indeed follow some ways to allow external CSS to leak into shadow root and components, including custom properties as well as ::part and ::theme pseudo-elements, which Monica Dinculescu has a good introduction.

Another thing to consider: the environment we are using. Three years after I personally built my web components, I can identify two environments: private environments (such as design systems) and standard environments (such as plain HTML, CSS, and JavaScript without custom styles).

Before designing components, we need to understand how they will be used, so determining the environment type is key to all of this. The easiest way is to target only one environment, but with a small CSS trick, we can build components for both .

Before we dig deeper, let's look at the difference between the two environments.

Private environment

A private environment is a closed ecosystem that provides components with their own styles and must be used as is. So if we are building a library of components from a specific style guide or design system, each component will reflect a custom style, so there is no need to encode it every time you need it.

The same is true for JavaScript logic. For example, we can attach a closed shadow root to prevent others from accidentally piercing the shadow boundary with querySelector. Therefore, we can simply select and use any component to avoid problems such as inconsistency in styles and CSS conflicts. As an author, you can also define a set of CSS custom properties (or ::parts) that can be used to style components for a specific use case, but this is not the focus of designing the system.

This is an example of using Web components in a private environment. All its styles and logic are contained in its shadow-root and can be simply added to any page.

This and subsequent examples are for demonstration purposes only and are not intended for production environments, as they do not take critical situations such as accessibility and other optimizations into account.

Components in private environments are rarely used outside of that environment. For example, if we try to get an element from a design system (with its own forced style), we can't simply add it to the project and expect to customize it. Do you know how Bootstrap can set up and customize the theme according to your preferences? This is the exact opposite. These components are intended to run in their environment and only in their environment.

Standard environment

Standard environments are probably the most complex component types, not only because environments can range from mature frameworks such as Vue and React to plain native HTML, but because everyone should be able to use the component as if it were any other element.

For example, when a component is added publicly (such as adding to npm), those who use it will expect to be able to customize it, at least to some extent.

Do you know of any HTML elements with their own demo style? The answer should be "no", because elements must be styled explicitly using CSS. The same is true for web components made in a standard environment. A single web component should be customizable by adding classes and properties or other methods.

This is the same as we see in the closed environment example<todo-list></todo-list> element, but it is designed for standard environments. It works as is, with no demo styles in its shadow root. In fact, it contains only the necessary logic and basic CSS to ensure its functionality. Otherwise, it can be customized like any standard HTML element (like a div).

The two examples we view for each environment were made using the same components. The difference is that components in a standard environment can be customized and selected using external CSS.

Web Components and Compositions

OK, so using web components is actually the same as using plain HTML, although as we can see, it is very important to follow the paradigms and principles of a given content. What we need to pay attention to is the combination of web components.

As Google Web Fundamentals explains:

Combinations are one of the least known features of Shadow DOM, but they are arguably the most important one.

In our web development world, composition is how we build applications declaratively using HTML. Different building blocks (<div> ,<code><s></s> ,<em></em> ,<strong></strong> ) put together to form an application. Some of these tags can even be used with each other. Combination is why<select></select> ,<details></details> ,<summary></summary> and<video></video> The reason why such native elements are so flexible. Each tag accepts certain HTML as child elements and performs some special operations on them. For example,<select></select> Know how to<option></option> and<optgroup></optgroup> Rendered as a drop-down list and a multi-select widget.<details></details> The element will<summary></summary> Presented as expandable arrows. even<video></video> Also know how to deal with certain child elements:<track></track> Elements are not rendered, but they do affect the behavior of the video. How amazing! Composition is what we usually do when using HTML. Since a web component is merely an HTML element with a DOM reference (not a logical container), we should rely on combinations to build our components and any subcomponents. If you consider

and<select></select> , you'll notice that you declaratively combine these elements to get the final output, and you have specific properties that can be used for the main component (e.g. [readonly] ) or the child component (e.g. [selected] ). The same is true for web components, if you are building a custom list, consider building the main component (<custom-list></custom-list> ) and subcomponents (<custom-li></custom-li> ). use<slot></slot> Elements, you can define where the child elements will be placed, and the placeholder content that will be displayed when the child elements are not passed.

Web Components and Accessibility

Another thing to consider is what we call the “small” theme of accessibility . Since we are creating a completely new HTML element, we need to consider the accessibility of the element in order to provide basic semantic roles, any keyboard navigation, and user's operating system preferences such as reduced motion and high contrast settings.

I strongly recommend the following resources as a reference for building accessible and inclusive components, how to define semantic tags, and how to implement basic keyboard navigation.

• Inclusive Components
• "Effect for everyone" on web.dev
• WAI-ARIA Creative Practice
• WebAIM WCAG Checklist

in conclusion

Web components are an emerging technology in web development, so there are no well-defined best practices to guide us when it comes to building them based on their intended use or maximizing use. When you find yourself using them, the only thing you might get from this post is to consider whether they are for closed or standard environments and ask yourself WHI :

• W ho Will use this component?
• H ow much flexibility This person should have to customize it?
• Is this component suitable for everyone or for a specific audience?