Using ‘fetch’ to Update the DOM
Updating the DOM (Document-Object Model) using ‘fetch’ in JavaScript can be very intimidating. There are a lot of moving parts and it can be hard to remember the steps required to complete the action. In fact, anything involving DOM manipulation is heavily dependent on what you want your website to do as well as how your DOM is set up. Despite the fact that specific steps can differ from application to application , we can break the action down to a few core principles so that you can always apply the same logic whenever you would like to update information that persists in the front-end and the back-end.

The ‘update’ action will generally always consist of three things happening:
- Listen for an action to occur to initiate the ‘update’
- Perform a ‘fetch’ with the method of ‘PATCH’ to update the back-end
- Have the ‘update’ reflected on the DOM
Step 1: Listen for an action to occur to initiate the ‘update’
In most cases, for an update to occur, an action needs to occur to initiate the actual ‘updating’. Whether it’s the user clicking on a checkbox or entering something into a form and hitting submit, we have to add an eventListener to a specific element in the HTML to ‘listen’ for a specific event to occur. As with every step listed here, this will be dependent on the application, but it will help to think about the user story. How and where would you, as the developer, like the user to initiate the ‘update’ action?

Once you have decided where to add the eventListener, pull the element out and add an eventListener to it. An eventListener takes a callback function to run when the event happens and this is where step 2 comes in.
Step 2: Perform a ‘fetch’ with the method of ‘PATCH’ to update the back-end
Inside of this callback function is generally where we would want the ‘fetch’ to occur. However, before we can initiate the ‘fetch’, we need to recognize and figure out exactly what it is we want to update (and therefore, ‘fetch’).
This is the step that will be most dependent and specific to the way your DOM is set up. Sometimes, the element that the eventListener was added to can already identify the specific object that is to be updated (perhaps through the id or name of that element). Other times, you need to reach a little further or be a little more creative in terms of identifying the specific object. Maybe the ID for the object can be located in a parent element. Wherever it is, make sure there is a way to ‘point’ to a specific object when the event to trigger the ‘update’ occurs.


Once you have a way of identifying the specific object to be updated, we can move on to the actual ‘fetch’ itself. If your application follows RESTful conventions, the URL that you will be updating to will have the ID of the object. For example, if you want to update a student’s name, and the student’s ID is 5, the URL might look like this:
`http://homepage.com/students/${student.id}`
where ID is being string-interpolated into the URL. The second argument of the ‘fetch’ will be an object with three keys: method, headers and body.

Because we want to update, the method will be “PATCH”. The headers will have another object of ‘Content-Type’: ‘application/json’ and/or ‘Accept’: ‘application/json’. The body will be dependent on what you want to update.
The body will have the method ‘JSON.stringify()’ with the data you are updating passed as the argument. If there are multiple attributes you wish to update, the data will be passed as an object in the argument.
Depending on what is being updated, you might want to pull the NEW data before this ‘fetch’ function and then assigning it in the body. This will be dependent on how you plan on getting the new data.

This will update the back-end with our new information. Although this data will persist and has been updated in our back-end, the DOM has not been updated to reflect this change.
Step 3: Have the ‘update’ reflected on the DOM
Just like with a simple GET request with ‘fetch’, we can use the ‘.then’ method to get a response back and use that response to change the DOM.

Inside our second ‘.then’, we will take the response that we get (which should be the new data in some form) and use that data to change the DOM in the same manner as always (grabbing the element to be changed and then changing it).
Although these steps are not very specific and generalized, they can be applied to any web application that involves updating the DOM dynamically. Updating will always follow the same core principles and, as such, these steps will always be relatively the same.

