Front-End System Design

MutationObserver Exercise

Evgenii Ray

Evgenii Ray

Staff UI Engineer
Front-End System Design

Check out a free preview of the full Front-End System Design course

The "MutationObserver Exercise" Lesson is part of the full, Front-End System Design course featured in this preview video. Here's what you'd learn in this lesson:

Students are instructed to create a mutation observer to detect text input and replace any supported tags with their corresponding HTML element.

Preview
Close

Transcript from the "MutationObserver Exercise" Lesson

[00:00:00]
>> Evgenii Ray: So I'm going to open this example in the full screen just to give you the idea what we're trying to build. So imagine the mark dominator where you can replace the content with some elements. So for instance, I want to replace this element with a heading. So the idea is to build such very simple examples of the market dominating to support h1 and h2 tag.

[00:00:23]
So if it's h1 because I have a normalizer, it will have the same styles. But if we check the example, we'll see that there is a h1 and h3 and as you can see, we can edit the direct content of the html element. So this is done through the content editable true attribute.

[00:00:46]
So if you have good examples of such capabilities and notion app, they heavily rely on such type of editing. So let's get back to the exercise. So first, let me read it, felt from the full screen and go back. So we're going to utilize the same example that we use before but we will add the content editable attribute to the section where we place the body text.

[00:01:16]
And we're going to create the mutation observer and trick all the subtree changes and the checked data so we can verify that we actually use the h3, or h2, or h1 tag. Then we implement the callback for mutation observer, and when we type, we need to validate that the text that we typed matches the tag to relace the content and when then we will need to replace that.

[00:01:44]
Make sure you're using the single observer for all rendered cards. Yep, and let's jump to exercise. Here's the branch name to start your work. Let's get back to the code. We have the same file in the index html file so that our template is here. But the create card element function now is in the utils.js, so we don't need to pay attention to that and also use the same Moog db.

[00:02:10]
And here we listed all the supported elements that we want to track h2, h2, and h3. That is also function called Get Heading that is very simple. It just it checks the text content of the element and then creates the specific html element.
>> Evgenii Ray: So let's get back to our index html now.

[00:02:36]
And here we need to initiate our mutation observer. And once we implemented the callback, we need to register that when we create the cart before we append them on the screen. So let's do that. So first of all the mutation observer accepts the mutation entries. So let's call it entries.

[00:02:59]
Now we need to look for the mutation entries.
>> Evgenii Ray: And so what we need to access, we need to get the target element.
>> Evgenii Ray: So when we got our target element, we also need now to filter out the mutation. So we are looking for the charted data type of mutation, and now we also want to check that, the target.textContent.

[00:03:42]
>> Evgenii Ray: That the element matches the following tech. So we can verify that by using this supported element, then we can have the has that will verify that the textContent matches any element in a collection. And if it does, then we are going to replace, we are going to create a new heading and use the getHeading method and pass our target node.

[00:04:13]
Okay, so now we have our heading method, we can now replace the target element using the method called replace with. So it basically replaces the target with a new heading element. And now we also want to focus on the newly created element. So now the mutation observer is implemented, but we still need to track the elements.

[00:04:40]
So here in the appendChild, what are we're gonna use is, we're gonna use the mutation observer, observe, and then our card element and the configuration. We're gonna use the subtree property to verify that. We do the deep check and the character data to true. The rest will be false.

[00:05:02]
>> Evgenii Ray: And if we open the, the last thing that we forgot is we need to add the content editable property to the section here to let the user edit the content. Okay, now if we run this example, now the content should be editable. And if we replace the tag with h3, we see that now the heading popped up.

[00:05:29]
Okay, so this was the mutation observer exercise. And here is the summary. So we created a mutation observer, accessed the target and a type of mutation, checked that the type is charged data. Check that the text content contains the specific set of characters we're looking for. Generate the heading element and replace it with a new element, yep.

[00:05:56]
>> Speaker 2: Is there a possibility of infinite recursion here where you're changing the target element and then it causes the mutation to fire again?
>> Evgenii Ray: Yes. So you need to be careful how you change that. So here, we do not check. We check only the character data mutation. It's basically when you type.

[00:06:18]
But because we insert the element and we update the element before we insert the data, the recursion is not happening.
>> Speaker 2: On a personal note, we use Google's CAPTCHA and the only way that we could detect that certain things were loaded was with the mutation observer because it was like they keep the third party APIs, in a sandbox or whatever.

[00:06:45]
And it's just like the only way to know if this dom was changed was with that API is interesting.
>> Evgenii Ray: You could potentially do the interval where you traverse the specific dom and looking for a sort an element, but it would be much slower than the Mutation observer.

[00:07:03]
>> Speaker 2: Yeah, and this way we were able to see is this element changed and if so, okay, then run our code. It was much more efficient. So it's good API.
>> Evgenii Ray: Any more questions before we jump to the next section?
>> Speaker 2: Someone else's said they use mutation observer in a chrome extension to make sure that the extension stays in sync with the rest of the web page that it was modifying.

[00:07:32]
>> Evgenii Ray: I think the grammarly, the popular exception for checking the grammar also use the mutation observer. They basically check what you enter on the data, but such extension may reduce your website performance.
>> Speaker 2: Yeah for sure.
>> Evgenii Ray: On the callbacks.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now