Codemotion Magazine

We code the future. Together

Home » Dev Hub » Frontend Developer » The DOM and its shadow
Frontend Developer

The DOM and its shadow

In this article you'll learn how to manipulate elements of a web page by guaranteeing proper encapsulation. How? Using the Shadow DOM.

by

The DOM and its shadow

Nowadays, most frontend web developers build their UI with well-known libraries and frameworks like React, Angular, Vue, and similar. Maybe many of them almost forgot the way to dynamically create HTML elements by accessing the Document Object Model (DOM). In fact, almost all these cool libraries abstract the DOM and provide their own model to produce HTML elements. And some of them even virtualize the DOM to optimize access.

So, why should a modern frontend web developer mind the DOM? After all, it sounds like low-level stuff that UI libraries handle efficiently.

This is how it looks. And for the most part, so it is. But the DOM is still there and any UI model eventually maps your code to the DOM, keeping its congenital defects.

The problem with the DOM

Most UI libraries have accustomed us to think the UI as a puzzle of components. This architecture is really awesome and promotes reuse, one of the most pursued principles of software development. However, the DOM has a major flaw that hinders composition and reuse: it is globally accessible.

It doesn’t matter where your UI element comes from: React, Angular, plain JavaScript. When your element is appended to the DOM, it can be accessed from any JavaScript code and CSS rules, and its internal structure can be changed.

The DOM is like a global variable. And all we know how global variables are bad.

So, when you add your UI component to the DOM, you may lose its alleged reusability due to the DOM’s lack of encapsulation.

Let’s try to explain what we are saying with an example.

Say you have created an awesome banner to invite your JavaScript community to your next great meetup. You want to distribute this banner to other websites so that all together can spread the word. You can build this banner in many ways: with pure HTML or using the UI library you prefer. It doesn’t matter. Regardless of the way you build it, its output will be a few elements on the DOM.

For our goal, assume that this is the JavaScript code that creates your banner:

function createBanner(elementId) {
 const banner = document.getElementById(elementId);
 banner.innerHTML = `
<style>
#box {
-webkit-box-shadow: 5px 5px 15px 5px #000000;
box-shadow: 5px 5px 15px 5px #000000;
font-family: Verdana, Geneva, sans-serif;
padding: 10px;
text-align: center;
width: 80%;
}
h3 {
font-size: 25px;
color: #5F36FF;
}
#description {
font-weight: bold;
font-size: 18px;
color: #6B6B6B;
}
#finalMessage {
font-weight: bold;
color: #6B2E63;
text-decoration: underline solid rgb(68, 68, 68);
}
</style>
<div id="box">
<h3>Join our awesome JavaScript meetup</h3>
<p id="description">You will learn the latest amazing way to forget JavaScript.<p>
<p id="finalMessage">Don't miss it!</p>
</div>
 `;
}

We use plain JavaScript, here. Just a function that takes the identifier of an element in the DOM and attaches some markup to it. If this code is stored in a file named banner.js, you can use it within an HTML page in the following way:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <script src="banner.js"></script>
  <script>
    window.onload = function() {
      createBanner("banner")
    };
  </script>
</head>
<body>
  <div id="banner"></div>
</body>
</html>

This page will be rendered as shown by the following picture:

Now, say that one of your friend websites uses a CSS rule like the following:

h3 {
  text-transform: uppercase;
  background: #0A59FA;
}

As a result of applying this rule, your banner will become like this:

Actually, not so good. This is not how we wanted our banner to look like.

But even worse, imagine somewhere in one of your friend websites there is a JavaScript code like the following:

document.getElementById("description").innerText = "I don't like JavaScript!";

Your banner will become as follows:

Eventually, you will agree that your banner is not safe. Its inner structure can be manipulated like any other element in the DOM.

How can you protect your work from accidental or intentional changes from the external environment? How can you guarantee encapsulation for your work?

The Shadow DOM

Traditionally, the DOM encapsulation problem has been tackled by using iframes. Put all the code of your banner into an iframe and it gets protected. But that solution solves one problem and introduce others. Actually, you have a simple and elegant solution for the encapsulation problem and its name is Shadow DOM. It is a set of standard APIs enabling the encapsulation of a portion of the DOM inside the DOM of an HTML page. It allows you to create a sort of private DOM for an HTML element. In other words, it enables a local DOM in contrast with the global DOM, just like global and local variables. The trick is very simple. Look at this snippet of code:

function createBanner(elementId) {
  const banner = document.getElementById(elementId);

  banner.attachShadow({mode: "open"});

  banner.shadowRoot.innerHTML = `
    <style>
      // The same stuff as before...
    </div>
  `;
}

We just invoked the attachShadow() method of the element to attach the Shadow DOM. This method is available for most HTML elements. It attaches to the banner element a node that represents the root of this local DOM. This root node can be accessed through the shadowRoot property. So, the content that before was directly appended to the banner element, now is appended to the shadowRoot property.

Open and closed Shadow DOM

As you’ve seen, a very little change to your code makes your banner impenetrable. Well, not exactly, actually.

You noticed that we passed a parameter to the attachShadow() method.

banner.attachShadow({mode: "open"});

It is a literal object with the mode property set to the open value. This object allows you to specify the creation mode of your Shadow DOM and it is mandatory. In the example above, we asked for an open Shadow DOM. This means that the elements that build up our banner will be protected by accidental interferences with CSS rules or DOM manipulation, but they are anyway accessible from the outside world. Actually, you can access them through the shadowRoot property, as shown below:

const bannerRoot = document.getElementById("banner").shadowRoot;
bannerRoot.getElementById("description")
  .innerText = "I don't like JavaScript!";

So, the internal parts of your banner are still accessible, but it has to be done intentionally. Also, you want it happens, since you attached the Shadow DOM with the open mode. If you don’t want so, if you want that the internals of your banner are invisible to the rest of the world, attach a Shadow DOM with the closed mode:

banner.attachShadow({mode: "closed"});

Now, your banner will be impregnable!

Conclusion

As we saw across this article, the DOM as known by most developers is not the best structure for hosting a composable UI. Its open accessibility exposes your UI elements to possible undesired conflicts. This factor clashes with the principle of composability and reusability we all want for our UI elements. In the article, we explored an example of such possible conflicts. But we also discovered that a simple and standard solution is available. In fact, you can overcome the lack of encapsulation of the classic DOM by using the Shadow DOM. A few JavaScript statements can save your work from external interference and make your UI elements really reusable.

Tagged as:

Related articles