Vanilla JS: You Might Not Need a Framework

Finding Elements in the DOM

Maximiliano Firtman

Maximiliano Firtman

Independent Consultant
Vanilla JS: You Might Not Need a Framework

Check out a free preview of the full Vanilla JS: You Might Not Need a Framework course

The "Finding Elements in the DOM" Lesson is part of the full, Vanilla JS: You Might Not Need a Framework course featured in this preview video. Here's what you'd learn in this lesson:

Maximiliano discusses selecting elements from the DOM, types of returns when selecting elements, functions that return a single element, and functions that return multiple elements. Common pain points when returning elements are also discussed in this segment.


Transcript from the "Finding Elements in the DOM" Lesson

>> Okay, so to work with the DOM API, we can select elements from the DOM. This is probably the, if you have ever seen a JavaScript course, or if you have ever read a book, or even a blog post on JavaScript, you have seen this basic part. You can select an element By its ID, the famous document get element by ID, we'll get there.

By Class Name, so when you want to pick an element from the DOM you can pick them By ID, and for that you need an ID, remember the ID in HTML is not mandatory. So if you don't set an ID of an element, you can't get an element By ID.

By Class Name, in this case it's the class declaration. By Name, this is the name HTML attribute that most of the time we use only for forms, but actually you can use it on other element as well. Means not common, but some library or some patterns will let you use that.

By CSS Selector that is currently today the most famous one, I mean, you picking element by using a CSS Selector that matches that particular elements or a group of elements. Or By Navigating the DOM Structure, so instead of looking into the the HTML itself you can navigate the structure because it's a tree structure.

We have parents, have children, okay, and we can navigate that structure. Yeah, it's a lot of work sometimes, but sometimes it's better, it depends on the case. When selecting elements, like I wanna get the IMG, I wanna get the link, when selecting these elements, some functions will return one element and only one element.

The element typically extends from HTMLElement. It can be A Live HTML Element Collection, and the class, I mean, the type that we receive is an instance of HTMLCollection. Live means that, for example, if you're looping through those elements, and also at the same time you have another code that is changing the DOM, it will change your collection on the fly.

I mean, you're getting all the elements with the class important and you're making a loop, for, looping through all the elements with class equals important. While you are looping a new HTMLElement appears in the DOM with class important. Well, you are changing the collection that you're looping. But some other functions will return a Static Element Collection, it's like a frozen at that moment.

And in this case, it's called a NodeList, so it's a different interface, okay, a NodeList. So it depends on the function that you're using, you can receive a NodeList or an HTMLCollection and the API is available there is not the same, okay? So to get one element, typically today, we use getElementByID if it has an ID or querySelector.

There other ways, like first child in case you are navigating through the DOM. But the most common are getElementByID and querySelector. getElementByID is from the first version of DOM, by the way, the DOM API has different versions. At this point, it doesn't matter, I mean, in the W3C, we have different specs, okay?

getElementByID is not exactly for the original one, but from the 90s anyway, getElementByID is from the 90s. querySelector is more modern has probably today 15 years, something like that. querySelector will let you get the first element matching a CSS Selector. So if you say h1, it will take the first h1, if you have more than one, just the first one, it will return one element.

Have in mind, when you use these functions that are returning one element, you can always get null in case no node was found. So you're getting an elementByID and the ID does not exist in the HTML, you get null, okay, makes sense? So here you have an example, this is a very basic JavaScript like JavaScript 101 with a DOM.

So you create a variable element document.getElementById, you pass an Id as a string. And, so, have in mind that element can be null, in case it doesn't exist in the current DOM, okay? If it's querySelector, you pass a CSS Selector such as in this case you will find, the first element matching that selector it's a link that's within a header, that is a direct descendant of a section.

And then you can deal with that element, you can change the contents, read the contents, add attributes, and so on. To get multiple elements so if you wanna get the collection of elements there are many ways getElementsByTagName, getElementsByClassName, querySelectorAll, and getElementsByName. This is not the full list, it's probably the most common ones.

And from this list querySelectorAll is the only one giving you on a static collection, okay? And be in library static for most situations I will argue that, it's not going to make a big difference for most use cases. But we have a big difference, okay, you will see that in a second.

When you use functions returning multiple elements, if there are no elements you won't get no, you will get an empty array or an empty collection. And when I say array because sometimes it's not really an array, okay, but it has an array like interface anyway, on every situation.

So for example, here I'm using querySelectorAll, that receives also a CSS Selector, but it's always returns a collection. In this case, it's given me the list items of an ID nav-menu, okay, that's all, it will give me a collection. This is a live collection, getElementsByClassName, document.getElementsByClassName("important"); in this case, it will look for elements with the important class.

Here comes the weird part mostly if you are coming from React or Angular or Vue where we are used to use the latest version of ECMAScript. So HTMLCollections, so the ones that are live, they don't have all the modern Array interface, for example, filter, map, reduce, forEach, we don't have that.

So we are using getElementsByClassName you cannot use filter or forEach. The only one from this list that let us do that is querySelectorAll. So if you make a querySelectorAll, even if you are passing a class name, so it will be similar to getElementsByClassName, but that collection will have filter, map, reduce, forEach, okay, makes sense?

You can still wrap your live collection, and have those methods, if you wrap them in an array using Array from. So you pass Array from you pass the documents getElementsByName collection, and then you can filter that is a little hacky, okay? But if you're used to functional programming in JavaScript and you'll see how that works is I'm gonna work with getElementsByTagName initially, okay?

So you need to wrap it into Array.from, char actually, for example, you will filter, make sense? That's because originally with the DOM API was created, we didn't have those array methods. So no one thought about that initially, and they don't wanna change that implementation because we want backward compatibility.

So they don't change that part, but the new part of the DOM API is different. But we can still wrap it and modernize that API, that makes sense? Cool, and now that we have reference and we will see this in action in a minute, when we have an element, using getElementsById, getElementsByClassName or any of the options.

We can read and change attributes' values, read and change styles, we can hook event listeners to that element, we can add or remove or move children, read and change content, and there are more APIs. In fact, new W3C APIs sometimes are adding new properties and new methods or new events to those elements.

For example, drag and drop, drag and drop or multi-touch for working with an iPad, for example, or the pointer API, so you can work with an Apple pencil or a Samsung pen. Those APIs are new W3C aspects that are adding new interfaces, new methods, new event names, new properties to these DOM elements.

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