You might already know that frontend development requires just three technologies upon which the entire web is built: HTML, CSS, and JavaScript. In the not-too-distant past, the feature set of these standards lagged behind the functional wishes of developers and designers. They couldn't build the web sites they wanted to build with the tools they were given. To work around this, several independent teams each devised their own frameworks to supplement what was officially supported by browsers. In one sense, these frameworks worked well. They introduced new UI patterns and dynamic websites at a time when desktop and mobile browsers were still in divergence. But at the same time, each framework was proprietary and unique. The skills and techniques you learned in one would not be transferable to another. Each framework handled page rendering differently, had a different language syntax, and in general, worked differently across browsers. Since then, web standards have matured, to the point where many of these frameworks have been made obsolete. The new paradigm for frameworks is to embrace, not obscure, native web functionality. In this post, we're going to introduce some of the new functionality offered by , a cross-browser solution for building complex web apps. We'll also introduce Salesforce's (LWC) as a fast, enterprise-grade wrapper around these web standards. web components Lightning Web Components Shadow DOM The , or document object model, is essential to how web pages operate. You can think of the DOM as a tree-like structure which a browser uses to understand the layout of a page. When you write HTML that looks like this: DOM <html> <title>DOM differences</title> <style>
   h1 {
     color: green
   }
 </style> <body> < html> < > head </ > head I belong to the light DOM < > h1 </ > h1 /body>
</ The browser sees a structure like this: html
 |
 | head
   |
   | title
   | style
 | body
   |
   | h1 Recent web standards additions have introduced the concept of a . The shadow DOM is a web API that lets you attach a DOM subtree which elements are "hidden". Taking the example from above once again, let's assume that we want to add another h1 element--only this time, attached to the shadow DOM. The browser would interpret that tree like this: shadow DOM html
 |
 | head
   |
   | title
   | style
 | body
   |
   | h1
   ---------- (shadow boundary)
     |
     | h1 The shadow DOM introduces a distinction called a "shadow boundary," which is created around the elements in a shadow DOM. Essentially, any styles applied to the regular DOM are not going to leak through this shadow boundary. As well, JavaScript events that are fired in the shadow DOM won't affect elements outside of it by default (although this behavior can be intentionally overwritten). This enforces a strict sense of division, and enforces encapsulation between HTML elements. That's a lot of technical talk: what's it actually mean? Well, let's modify our HTML page by adding a new element to the shadow DOM: <body> <script> el = .createElement( ); shadowRoot = el.attachShadow({ : });
   shadowRoot.innerHTML = ; container = .querySelector( );
   container.appendChild(el); < I belong to the light DOM < > h1 </ > h1 const document "div" const mode "open" "<h1>I belong to shadow DOM</h1>" const document "body" </ > script /body> Here, we're creating an element entirely in JavaScript. By calling the attachShadow  method, we've effectively added it to the shadow DOM. (The mode:open attribute simply means that the element can be queryable from outside of the shadow DOM' we'll get to that next.) After that, we add this new element to the body of the HTML page. If you were to create this page and open it up, you would see this: In many ways, this is surprising! After all, the CSS rule at the top of the page says that every h1 should be colored green. But, because the second h1 is actually on the shadow DOM, outside styles and JavaScript events won't affect it. In fact, on this same page, you could even do a quick query for all of the h1 elements: .log( .querySelectorAll( ).length); .log( .querySelectorAll( )[ ].textContent); console document "h1" console document "h1" 0 This would print out a count of 1, followed by the text message in the first DOM. That's because, from the outside, elements in the shadow DOM are not automatically accessible. But, because we set the mode to open, there is a technique we can use: .log(el.shadowRoot.querySelectorAll( ).length); .log(el.shadowRoot.querySelectorAll( )[ ].textContent); console "h1" console "h1" 0 With the shadowRoot property, you can query the shadow DOM elements nested underneath an element. How does LWC make this easier? Normally, one wouldn't define shadow DOM elements on the same page as the HTML. You'd create a separate JavaScript file and set up your element there: { () { (); .attachShadow({ : });
 }
 connectedCallback() { .log( .shadowRoot.querySelector( ));
 }
} class MyWebComponent extends HTMLElement constructor super this mode "open" console this "h1" Every web component would need to follow the same pattern: create a constructor, and use attachShadow to add the element to the shadow DOM. But, LWC simplifies all of this setup logic for you: {
 connectedCallback() { .log( .template.querySelector( ));
 }
} class MyLightningWebComponent extends LightningElement console this "h1" By simply extending the LightningElement class, a component built using LWC attaches itself to the shadow DOM. This guarantees the encapsulation with a nice syntactic sugar developer's don't need to memorize. In addition, not every browser supports the shadow DOM natively, particularly those that are over several years old. In these instances, LWC provides a polyfill that ensures the shadow DOM compatibility everywhere. Custom Elements Elements are the basic foundation of every HTML page. For example, a div tag holds multiple items, a span can wrap phrases, and lis can compose ordered (ol) or unordered (ul) lists. are reusable HTML components which developers create, in order to create reusable HTML components that can act and look in any way you want, as if they were standard elements. Custom elements Suppose you wanted to create a custom element, <flag-icon>, which would display some visual indicator to a user. In vanilla JavaScript, you would create and register the custom element like this: { () { (); .attachShadow({ : }); span = .createElement( );
   span.innerText = ; .shadowRoot.appendChild(span);
 }
}
customElements.define( , FlagIcon); class FlagIcon extends HTMLElement constructor super // Define custom element this mode "open" const document "span" "I'm a flag icon" this "flag-icon" First, you define a class (FlagIcon), which needs to extend from HTMLElement, which is a web standard. You'd need to create the element using JavaScript methods, fill in the text, and attach it to the shadow DOM. Finally, you need to remember to define the class and provide its tag name. How does LWC make this easier? Creating a custom element using LWC reduces much of the repetition: { () { (); span = .createElement( );
   span.innerText = ; .template.appendChild(span);
 }
} class MyLightningWebComponent extends LightningElement constructor super const document "span" "I'm a flag icon" this Once you extend from LightningElement, LWC knows two things: it knows you want to  attach a shadow DOM to the element, our web component, as we saw previously, and it knows you want to define this as a custom element. Rather than having to write this repetitive logic, LWC handles all of this background maintenance for you, allowing you to focus on your component's look and feel. HTML Templates Now, it's actually rare to have custom elements define in pure JavaScript. It can get pretty tedious. That's where the tag comes into play. <template> A <template> tag allows you to define the structure of your custom element using HTML. In other words, it defines reusable markup which you can use as the basis for your custom element. For example, we might want our <flag-icon> to look like this: <template id= > < "flag-icon-template" I'm a flag icon < > span </ > span /template> You can add this markup anywhere on your page, and the browser will know not to render anything in the <template>. It's completely invisible, and the way to attach it to the page is similar to the way any custom element is defined: { () { (); .attachShadow({ : }); template = .getElementById( ); clone = template.content.cloneNode( ); .shadowRoot.appendChild(clone);
 }
} class FlagIcon extends LightningElement constructor super this mode "open" const document "flag-icon-template" const true this Here, rather than using JavaScript's createElement method, we fetch the custom element's markup through its id via getElementById. Then we attach it to the shadow DOM as before. How does LWC make this easier? If you're using LWC, you'll need to do two steps to define the custom component: 1. Copy all that same <template> markup and add it to a file that matches the name of your custom element (like, myLightningWebComponent.html) 2. Create a JavaScript file that looks like this: {

} class MyLightningWebComponent extends LightningElement Yep, that's it. There's no code necessary to create a shadow tree, no code to create a custom element, no code that attaches the HTML template. Everything is done automatically for you. LWC is going to create all of that boilerplate code for you! Conclusion Stronger web standards have returned some sanity to frontend development. Instead of several proprietary frameworks bolting on functionality to web sites, web standards, which are guaranteed to function the same in any browser, allows developers to write clean and consistent code. LWC takes this simplicity further by abstracting away much of the repetition. LWC can do more than what we've talked about here. There's a whole swatch of performance improvements, integrations with Salesforce, and even to start using. a whole library of components If you'd like to know more, they've got a video on , as well as . There's also that walks you through building several projects that use LWC. the shadow DOM custom elements and HTML templates a Trailhead trail

Fetch

Salesforce

Super

How to Build a Meme Generator with RedwoodJS

How to Build Progressive Web Apps with Lightning Web Components [Part 2]

I write about technology michael.bogan@gmail.com

Nominated for 2022 - HackerNoon Contributor of the Year - Software Architecture

Nominated for 2022 - HackerNoon Contributor of the Year - Microservices

Nominated for 2022 - HackerNoon Contributor of the Year - Devops

Nominated for 2022 - HackerNoon Contributor of the Year - Api

Nominated for 2022 - Software Developer of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Software

Too Long; Didn't Read

Understanding Web Standard - Shadow DOM and Custom HTML Elements

Understanding Web Standard - Shadow DOM and Custom HTML Elements

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

10 Threats to an Open API Ecosystem

A Guide for Using Native ECMAScript (ES) Modules

Beginners Guide to Analysis Techniques

Building Blocks of DOM Manipulation - Vanilla JS Tutorial (Part One)

Building TicTacToe Using Vanilla JavaScript

10 Threats to an Open API Ecosystem

A Guide for Using Native ECMAScript (ES) Modules

Beginners Guide to Analysis Techniques

Building Blocks of DOM Manipulation - Vanilla JS Tutorial (Part One)

Building TicTacToe Using Vanilla JavaScript

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps