STEP 1: FETCH
const BASE_URL = "http://"insert-link-or-local-reference-here/"
Once you have declared your global variable we must now access its information. To do this we perform a FETCH request of the URL which will allow us to parse through its metadata structure and reorganize it into something more mailable. Let’s take a look at how we might do that:
We start by fetching the BASE_URL .then (think of this operator simply as the adverb “then”) we are taking the response (shortened here to res) and use an arrow function with its implicit return to render that into a response.json(). Here
console.log() to allow us to see that object promise in our browser console.
If we get an object response in our
STEP 2: LISTEN
The second step of our PATCH request is to identify the event we want to monitor or “listen” to. When triggered, this event will inform us that an attempt is being made to pass information to the server that we will use to update the HTTP. We monitor for these events through use of the method
.addEventListner(). There are many flavors of EventListners which can monitor for user events such ranging from mouse clicks to key presses to load or unloading.
As you probably noticed, the EventListener function begins with a “.” indicating it must first be attached to an element. We can attach these most anywhere from variables to HTML objects, the only important thing here is to remember that your target must be what you are attempting to monitor. Here are examples of a few simple ways to attach EventListeners:
The syntax here is purposefully generic and aims to demonstrate that you can attach these EventListeners to variables, elements, DOM objects and even connect them to the window object itself. Once you have found the home for the EventListener to live you can pass in several arguments. The event itself, which monitors for the type of EventListener (click, keydown, keyup, submit, etc.), and the function(s) you want the event to run. It is even possible to use an arrow function
=> to build out some logic inline.
STEP 3: DEFINE
Now that we have the EventListner connected to the element we want to listen to we need to define what information we hope to pass into our PATCH. This can be as simple or as complex as the functionality of your product demands, from a single line to entire arrays of objects. As your author at the time of writing is a beginner, we’re going to be starting with something pretty simple.
We’ll define the parameters of our PATCH by creating a variable with which to house the PATCH data. Examples of variables defining some patch data could look something like this:
Whatever data you try to PATCH make sure you have the correct address for where that data lives. Use your
debugger to help you find where that information lives and use the proper syntax to retrieve that data from its source!
Once we have established what data we want to pass to the PATCH, and built the code necessary to do so, we move on to translating that information back into JSON so the machine can interpret it. This brings us to step four, translate.
STEP 4: TRANSLATE
In this step we must take the data we wish to PATCH and translate it into language the machine can understand. An easy way to do this is to use the header, method and body operation and tie it to a variable. To do this we essentially request the object information we just created and run it through a few steps in order to refactor into the machine language. It is common to see this variable declared something like “reqObj” -request object. The structure of this bit of code can be written as simply as this:
Each key in this object perform a specific function necessary to reformatting the information for use by the machine. The headers (which must be spelled with the “s” to run) orients the data, the method defines the operation being performed, and finally the body reads the data you have defined and converts it back into JSON.
This brings us to the final step in our PATCH process, the final fetch and patch.
STEP 5: FINAL FETCH & PATCH
This step requires a bit of fancy footwork. It’s built similar to the first fetch we made at the beginning of this process; however, it requires two variables to be passed it *and* it requires you to modify the HTTP address. Finding the additional information required to update the URL can be tricky and it is often a good idea to add an ID to the element you have attached the EventListener. This final fetch and patch structure can look something like this:
Make sure to lean heavily on
console.log() and the
debugger here to make sure your updated URL is directing to the correct place in the HTTP and that the data being parsed out by
res.json() is the having the desired effect on your patch target. The example outlined above is a very simple version of what can be an incredibly complex and powerful tool. Entire functions can be passed in and logic applied to this process.