{"id":1957,"date":"2019-12-05T15:01:47","date_gmt":"2019-12-05T14:01:47","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/uncategorized\/the-dom-and-its-shadow\/"},"modified":"2021-12-23T15:20:09","modified_gmt":"2021-12-23T14:20:09","slug":"the-dom-and-its-shadow","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/frontend\/javascript\/the-dom-and-its-shadow\/","title":{"rendered":"The DOM and its shadow"},"content":{"rendered":"

Nowadays, most frontend web developers<\/strong> build their UI<\/span> with well-known libraries and frameworks such as React<\/span><\/strong>, Angular<\/strong>, Vue<\/strong>, and so on. Maybe many developers have almost forgotten how to dynamically create HTML elements<\/span> by accessing the Document Object Model<\/span><\/strong> (DOM<\/span><\/strong>). In fact, almost all these cool libraries abstract the DOM<\/span> and provide their own model to produce HTML elements<\/span>. Some even virtualize the DOM<\/span> to optimize access.<\/p>\n

Why then should a modern frontend web developer keep the DOM<\/span> in mind?\u00a0 After all, it sounds like low-level stuff that UI<\/span> libraries handle efficiently.<\/p>\n

That’s certainly how it looks, and for the most part, how it is, but the DOM<\/span> always remains present.\u00a0 Any UI<\/span> model eventually maps your code to the DOM<\/span>, retaining its congenital defects in the process.<\/p>\n

The problem with the DOM<\/h2>\n

Most UI<\/span> libraries have made us accustomed to thinking of the UI<\/span> as a puzzle of components. This architecture is really awesome and promotes reuse, one of the most avidly-pursued principles of software development. On the other hand, the DOM<\/span> has a major flaw that hinders composition and reuse: it is globally accessible<\/strong>.<\/p>\n

It doesn\u2019t matter where your UI<\/span> element comes from – React, Angular, plain JavaScript… When your element is appended to the DOM<\/span>, it can be accessed from any JavaScript code or CSS<\/span> rules, and its internal structure can be changed.<\/p>\n

The DOM<\/span> is like a global variable. And all we know how bad global variables are.<\/strong><\/p>\n

As a result, when you add your UI<\/span> component<\/span> to the DOM<\/span>, the UI may lose its alleged reusability due to the DOM<\/span>\u2019s lack of encapsulation<\/span>.<\/p>\n

Let\u2019s explore this point with an example.<\/p>\n

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 they can all spread the word. You can build this banner in many ways, with pure HTML<\/span> or using the UI<\/span> library you prefer. It doesn\u2019t really matter – regardless of how you build, the output will be a few elements on the DOM<\/span>.<\/p>\n

For our purposes here, assume that this is the JavaScript<\/span> code that creates your banner:<\/p>\n

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<\/span> meetup<\/h3>
<p id=\"description\">You will learn the latest amazing way to forget JavaScript<\/span>.<p>
<p id=\"finalMessage\">Don't miss it!<\/p>
<\/div>
 `;
}<\/pre>\n
We’ve used plain JavaScript<\/span> here: a simple function that takes the identifier of an element in the DOM<\/span> and attaches some markup<\/span> to it. If this code is stored in a file named banner.js<\/em>, you can use it within an HTML<\/span> page in the following way:<\/p>\n
<!DOCTYPE html>
<html lang=\"en\">
<head>
  <meta charset=\"UTF-8\">
  <script<\/span> src=\"banner.js\"><\/script<\/span>>
  <script<\/span>>
    window.onload = function() {
      createBanner(\"banner\")
    };
  <\/script<\/span>>
<\/head>
<body>
  <div id=\"banner\"><\/div>
<\/body>
<\/html<\/span>><\/pre>\n
This page will be rendered as shown in the following image:<\/p>\n
\"\"<\/picture><\/figure>\n
Now, say that one of your ‘friend’ websites uses a CSS<\/span> rule like the following:<\/p>\n
h3 {
  text-transform: uppercase;
  background: #0A59FA;
}<\/pre>\n
As a result of applying this rule, your banner will look like this:<\/p>\n
\"\"<\/picture><\/figure>\n
Not so good – this is not how you wanted your banner to look.<\/p>\n
Even worse, imagine that somewhere in one of those other websites there is a JavaScript<\/span> code like this:<\/p>\n
document.getElementById(\"description\").innerText = \"I don't like JavaScript<\/span>!\";<\/pre>\n
Your banner will now look like this:<\/p>\n
\"\"<\/picture><\/figure>\n
Eventually, you will decide that your banner is not safe. Its inner structure can be manipulated like any other element in the DOM<\/span>.<\/p>\n
How can you protect your work from accidental or intentional changes from the external environment?<\/strong> How can you guarantee the encapsulation<\/span> of your work?<\/p>\n
The Shadow DOM<\/h3>\n
Traditionally, the DOM<\/span> encapsulation<\/span> problem has been tackled by using iframes. Put all the code for your banner into an iframe and it is protected<\/span>. That solution solves one problem, but it introduces others. In fact, there is a simple and elegant solution for the encapsulation<\/span> problem, and its name is Shadow DOM<\/span><\/strong>. It is a set of standard APIs<\/span><\/strong> that enable the encapsulation<\/span> of a portion of the DOM<\/span> inside the DOM<\/span> of an HTML page. This allows you to create a sort of private DOM<\/span> for an HTML element<\/span><\/strong>. In other words, it enables a local DOM<\/span> in contrast with the global<\/span> DOM<\/span>, just like global<\/span> and local variables<\/span>. The trick is very simple. Look at this snippet of code:<\/p>\n
function createBanner(elementId) {
  const banner = document.getElementById(elementId);

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

  banner.shadowRoot.innerHTML = `
    <style>
      \/\/ The same stuff as before...
    <\/div>
  `;
}<\/pre>\n
We just invoked the attachShadow()<\/em> method<\/span> of the element to attach the Shadow DOM<\/span>. This method<\/span> is available for most HTML elements<\/span>. It attaches a node that represents the root of the local DOM<\/span> to the banner<\/em> element. This root node can be accessed through the shadowRoot<\/em> property. The content that was previously directly appended to the banner<\/em> element is now appended to the shadowRoot<\/em> property.<\/p>\n
Open and closed Shadow DOM<\/h2>\n
As you\u2019ve seen, a very little change to your code makes your banner impenetrable. Well actually, not quite.<\/p>\n
You noticed that we passed a parameter to the attachShadow()<\/em> method<\/span>.<\/p>\n
banner.attachShadow({mode: \"open\"});<\/pre>\n
This is a literal object with the mode<\/em> property set to the open<\/em> value. This object allows you to specify the creation mode of your Shadow DOM<\/span> and it is mandatory. In the example above, we asked for an open Shadow DOM<\/span>. This means that the elements that build up our banner will be protected<\/span> against accidental interference from CSS<\/span> rules or DOM<\/span> manipulation, but they remain accessible<\/span> from the outside world. In fact, you can access the elements through the shadowRoot<\/em> property, as shown below:<\/p>\n
const bannerRoot = document.getElementById(\"banner\").shadowRoot;
bannerRoot.getElementById(\"description\")
  .innerText = \"I don't like JavaScript!\";<\/pre>\n
So, the internal parts of your banner are still accessible<\/span>, but it has to be done intentionally. By attaching the Shadow DOM<\/span> with the open<\/em> mode you chose for this to be possible. If on the other hand you don\u2019t want access to be possible, if you want the internal workings of your banner to be invisible to the rest of the world, attach a Shadow DOM<\/span> with the closed<\/em> mode:<\/p>\n
banner.attachShadow({mode: \"closed\"});<\/pre>\n
Now, your banner will be impregnable!<\/p>\n
Conclusion<\/h2>\n
As we saw inthis article, the DOM<\/span> most developers know is not the best structure for hosting a composable UI<\/span>. Its open accessibility<\/span> exposes your UI<\/span> elements to possible undesirable conflicts. This factor clashes with the principle of composability and reusability we all want for our UI<\/span> elements. We have explored an example of such possible conflict, but we have also discovered that a simple and standard solution is available. The lack of encapsulation<\/span> of the classic DOM<\/span> can be overcome by using the Shadow DOM<\/span>. A few JavaScript statements can save your work from external interference and make your UI<\/span> elements really reusable.<\/p>\n