Web Components - Part 1

Front-end web development has become incredibly complex over the years. Back in the day the only things you needed to become a front-end web developer was HTML, CSS and some basic JavaScript or if you were fancy then you would learn jQuery. But the issue ‘back in the day’ was that browsers would rendering of elements would be different so as web developer we would have to use hacks to make things look acceptable.

Today, we have a number of front-end libraries/frameworks that offer front-end developers some incredible super powers, the problem with them is that most of us don’t utilise all the features that we import with the libraries/frameworks. To make things even worse depending on the preference of the developers working on a project you end up using different libraries for different projects. Wouldn’t it be nice if we could have a set of components that could be used across projects and across libraries/frameworks?

NB: Henceforth when I libraries I am referring to libraries/frameworks

Enter

[Insert Bollywood Explosions here]

Web Components were originally introduced in 2011 and browsers started implementing them much later.

---

What are Web Components?

Web components are a set of web APIs that allow developers to make encapsulated components that have their own set of functions and styling.

Web components are made up of

• Custom Elements
• Shadow DOM
• ES Modules
• HTML Templates

For this article I will be focusing on Custom Elements.

---

Custom Elements

The need for Custom Elements

HTML provides a number of tags that have been serving the web well but the issue comes in when you try to get a consistent look and feel for various HTML tags. CSS tries to solve this by having a global style sheet that houses all the UI styles, however, this gets very difficult to manage with multiple developers since most developers would end up writing styles at the bottom of CSS files which makes it difficult to manage the styling.

To address this various frameworks and libraries have come up such as React and VueJS that let you encapsulate/scope styles. This solution of course works well when you have the freedom of importing libraries but what if you would like to achieve the same without using a particular library or framework. This is where Custom Elements in. As a PoC lets look at how an ecommerce front-end would look like with Custom Elements .

The Design

Very simple design of an e-commerce store that we will be implementing to figure out how Custom Elements work.

Basic HTML Implementation

https://codepen.io/davinderpal/pen/abNwoBp

CodePen showing implementation using basic HTML

Converting To Custom Elements

We have tried as much as possible to provide semantic meaning to the markup but there are places that the tag chosen doesn’t make sense. If a different developer was to continue this project they would would probably use different mark up, e.g. instead of using a p tag for the price they could use a div , this won’t cause any issues in styling since we are using the classes to do the styling but it does make our codebase very inconsistent, therefore, harder to manage.

Instead we could convert the mark up to a custom element and abstract the implementation. So having a custom element such as

<shop-product
  image='https://source.unsplash.com/200x200/?shoes'
  name='Nikey Shoes'
  price='$40'
  rating='1'
  variants='100'
></shop-product>

would ensure that any developer creating a new shop page would have a consistent way of describing the elements. There is an added advantage of making our code base slightly more readable.

https://codepen.io/davinderpal/pen/bGpaNpG

As you can see from the Pen above both implementations look exactly the same to the end-user, but the below one has a more consistent codebase with less chances of a different developer changing markup in a different page. This also makes the code reusable across pages and even sites.

---

The Implementation

To register a custom element you have to JS with the window.customElements.define (or customElements.define)function which takes in 2 required arguments and 1 optional argument.

• The first argument is the name of the custom element that you are creating. The docs require that the name of the custom element needs to include a hyphen — in its name. This is usually a string.
• The second argument is the constructor that defines how the element will actually be implemented. This is usually a class.
• The third argument is an options object. This is out of scope for this article but in the coming articles I will be covering this more.

The way JS is structured you will need to declare the implementation class before trying to register the custom element.

The implementation class extends the HTMLElement class and as such inherits all the functions and events that a normal HTML element would have. Within the new class we only require to provide the constructor which starts by calling the super() function.

class Product extends HTMLElement {
  constructor () {
    super()
  }
}

Within the constructor you would create the HTML elements that are required for the implementation of the custom element. This code can be seen within the CodePen above.

Conclusion

Creating custom elements really helps have consistent and reusable code for web applications. This also lets you hide some of the inner workings which let developers who are not very familiar with front-end development still write front-end code.