How I Learned to Stop Worrying and Love the DOM.

     The first few weeks of class at the Flatiron school have brought a whirlwind of new concepts to learn, people to meet, and thrilling possibilities to consider. It’s hard to believe that we’ve already completed our first phase of learning and put together a project that incorporates each of the skills we’ve developed so far. It has been remarkable to watch the seemingly disparate languages and concepts we are learning come together to build something cohesive and usable. In this blog post I want to talk about how they all meet and work in tandem to create the modern web that we use every day.

     Some of the topics we covered in this phase were how to give basic structure to a webpage with HTML, how to clad the content in the design that makes it readable and engaging, using CSS, and finally how to add functionality and dynamic tools to a webpage using functions and instructions that we create and import from JavaScript. Together, these three elements constitute something called the DOM, or document object model. Understanding the DOM is key to understanding how and why websites work the way they do – and of course how to find your mistakes when they do not.

     I ran into some challenges during a few labs that at first baffled and frustrated me, but ultimately led to a better understanding of the concept which has helped me in all of the work since.

     The DOM is a structure used when you import code into your HTML that defines the way the page is presented and how it can be interacted with according to instructions written in CSS and JS. These components work together as objects within the document, to define its behavior. But where is the DOM? When I first read about the term I thought of it as a purely conceptual description of the result of a process that renders these three distinct sources of code to a browser. Close, but not quite right. This understanding led to some confusion about how and where data could be stored in a page after being defined by our javascript. If my initial understanding were correct, then every piece of data on the page would need to be stored either in the plain HTML or in variables in the JS, right? Yet I found after implementing content to a page, we could reference information not contained in either. How could that be? Take the following code, for instance:

fetch("https://api.punkapi.com/v2/beers")
.then(res => res.json())
.then(beers => {
   beers.forEach(fillBeerList);
   return beers;
})

const fullMenu = document.querySelector("#full-beer-list");
const searchForm = document.querySelector("#search");

function fillBeerList (item)
{
   const menuItem = document.createElement("li");
   menuItem.textContent = item.name;
   fullMenu.querySelector("ul").append(menuItem);
   menuItem.addEventListener("click", () => renderBeerDetails(item));
}

     In this code, from my project, we take information imported from a database – in this case a library of data about beers at a brewery – and use this data to create an interactable menu. After the data is returned, we use a forEach function to create a clickable list item for every menu option. When clicked, the website should display details about the selection, taken from the api, via the callback function “renderBeerDetails(obj)”. (see below):

function renderBeerDetails(brew) {
   currentBeer = brew
   beerName.textContent = brew.name;
   tagline.textContent = brew.tagline;
   firstBrew.textContent = brew.first_brewed;
   description.textContent = brew.description;
   abv.textContent = brew.abv;
   ibu.textContent = brew.ibu;
   image.src = brew.image_url;
   faveIcon.src = "./assets/beer/png/001-beer.png"
}

     Finally, we append each of these items to a node representing the menu. – It’s clear enough how each new item is appended to the structure of the page, but if the code has to execute before passing on, and each pass of the function reuses the same variable, then how is the information on the specific beer-to-render stored and, more importantly, referenced, during the click event? The answer – as far as I understand it – is that each execution of the code, and therefore the details we pass through to the callback function, is stored in and can be referenced in a separate node on the document. Because the website consists of objects in this overarching structure, called the ‘document’, each event listener created in this code is able to instruct the website to render information on the correct beer without using a unique variable in JS.

     The result of this code is an important tool in the functioning of our phase one project. take a look at the finished results below (complete with CSS styling):

     When I first saw code like that in the examples above, I could not understand how it worked. How did our event listeners know which beer object to render if the content had been changed on each pass of the function. Now I understand that the DOM is more than a metaphor for the admixture of the three building blocks of the web, css and JS working on HTMl. It is an actual object, or structure which contains working sections of code and nodes of html that can be made interactable on myriad data.

     This has been my attempt to make sense of the structure of the "document object model" and all of the capabilities it brings. The truth is, I still have so much to learn and my understanding is far from complete, but this small concept helped me to understand and write code better and I wanted to share that experience with everyone reading. Please feel free to reach out to correct any misunderstanding I may have included here by mistake. This metaphor was helpful for my understanding, but is obviously incomplete. Since my only goal in writing is to reflect, hopefully understand the topic better, and connect with others in the coding community, any info that brings that vision into clearer view, is abundantly welcome.