You’ve heard of the DOM. Most of the time you’ve heard bad things. DOM traversal slow! DOM operations are expensive! DOM API is a mess! Its true that the DOM gets its share of bad press but when we take a step back and calm ourselves, we realize that the DOM is the most critical part of what we do as web developers and it’s of paramount importance that we make an effort to understand it.
DOM or the Document Object Model is the object graph representation of the declarative HTML markup. Every HTML tag gets translated into an object internally. For example, a simple <div> gets translated into HTMLDivElement or a <span> gets translated into an HTMLSpanElement. When the parser runs, it knows which object to instantiate based on the markup that it encountered. Essentially, every HTML tag is backed by a class.
W e know that some HTML elements encapsulate their representation. An example being the <h1> tag. We know that whatever text we enclose within an <h1> tag has its font-size at 2em, font-weight bold and display block. Some elements take attributes that dictate some behavior. An example being the <a> tag which takes an “href” attribute which allows us to link to a different page. This ability of encapsulating representation and behavior is achieved by the browser’s internal APIs that are used to implement different types of elements.
Enter web components. Web Components are a set of lower level APIs that the browser exposes so that they can be used to develop custom elements which can encapsulate representational logic and behavioral logic. Since web component APIs are native to the browsers, these custom elements can function framework and library free natively on a browser that supports the web components specification.
Web components primarily composes of 4 features:
Lets dig deeper into each one of these features and the part you’ve been waiting for…the code!
The simplest way to create a custom element is to extend HTMLElement and register the element part of the browser’s vocabulary.
The element can now simply be used like any other HTML tag.
However, we see no difference. This is because no implementation has been defined for this custom element. Lets add that in.
Now, if we just use <name-tag></name-tag> as an HTML element, we see the following output on the page:
This is a custom element
Lets make our element a little bit smarter. For the custom element to be usable, it must have a public API through which properties can be provided to the element which would dictate how the component would render. Lets implement this behavior with the intention that we will use the element like <name-tag name=”John Doe” />:
Lets summarize the workflow for a custom element:
If you have followed along, you’ve created your first custom element. As promised, this element will work natively on any browser that is web components compliant. We will get to how we can ship the custom element at a later post.
We will come back to custom elements since the posts are meant to build on top of each other. Stay tuned for Part II where we look at Shadow DOM.
Hacker Noon is how hackers start their afternoons. We’re a part of the @AMIfamily. We are now accepting submissions and happy to discuss advertising &sponsorship opportunities.
To learn more, read our about page, like/message us on Facebook, or simply, tweet/DM @HackerNoon.
If you enjoyed this story, we recommend reading our latest tech stories and trending tech stories. Until next time, don’t take the realities of the world for granted!
Level up your reading game by joining Hacker Noon now!