Fetches and Promises

Today we’re going to have an in depth discussion of fetches and their infamous and inevitable children: the promises. Fetching is at the heart of the relationship between what web developers call the front end and the back end of a web application.

The back end is essentially a code framework that is designed to handle data in a very particular way. Languages that are commonly used for backend systems are Python, Ruby, and Node.js, but there are myriad ones that are available. Instead of having a pile of numbers and names, backend systems can organize their data in a particular way so that, when called upon by the front end, it can be formatted in a way that is amenable to what the front end might ask of it. For example, if you have a user object that has a bunch of attributes like name, age, sex, the backend can produce that information for the front end in a way that might present all that information as a string, or as an array, or how ever might be optimal.

The front end, on the other hand, is almost exclusively an amalgam of three separate programming languages, namely HTML, CSS, and Javascript. HTML is a the skeleton on which everything else rests. It defines delineated areas on a web page, so that the other two pillars of front end programming can spruce it up. CSS can change the size, color, and orientation of CSS elements as well as many other attributes that combine to make a plain HTML document come alive. Finally, Javascript is the breath of air that makes web pages interactive and dynamic. Using Javascript, developers can program features that allow feedback from app to users. Javascript is also the portion of the front end trinity that engages in that vaunted maneuver, the fetch, which is what we’re all here to talk about. Because getting information from the backend to the frontend is no simple feat. For one thing the data that the backend houses has to be hosted somewhere. If you are merely working in the closed circuit of your own computer, this information can be locally hosted on your own computer. But if at any point you want your app to be accessible to anyone not using your own computer, your backend will have to be hosted on any of the various services there are available for deployment. Once that’s sorted, you’re well and ready to go about fetching. Here’s what it looks like:

fetch('localhost:3000/parameters-here')

The URL for the fetch request is passed in as a string for the argument of the fetch function. If you are using Ruby, you will have set up what are called routes. These are essentially signposts that a frontend can call upon to get specific information, and they are called by passing in specific parameters to the right of the URL for your backend. Here’s where it gets tricky. This is what a full fetch request looks like.

fetch('localhost:3000/parameters-here')
.then(res => res.json())
.then(data => someFunction(data))

There are a couple steps to break down here. First the .then. Javascript works asynchronously, which is to say it allows for some things to happen before other things. Web pages need to be very quick as most people have a terrible attention span. Using an asynchronous function like “then” allows the basic framework of the page to load up, before the data has a chance to come back from the front end. A consequence of this is that an asynchronous function like then will, instead of returning the data proper that it fetched, will return something called a promise. A promise behaves a little differently than most data types. If the fetch was executed correctly, the promise will be fulfilled, and then you will need a function to deal with the returned promise. Using arrow notation you can name the return anything, as long as you use the same vocabulary when applying the function to the response. Almost always you’ll want to use the “.json” function as this point. Ruby converts its data into the json format for transfer to the front end, and using the “.json” function will render the data readable in a javascript format.

At this point, if you are using React, you’ll probably want to put the response in state. To do that, set up another arrow function and use your setter method on the response of the promise. When defining your promise, you can also set up an error message, using the throw syntax. Putting a string after the throw bare word will set up an error message so that will be printed if the promise runs into any trouble.

Another common issue that arises with promises and asynchronous functionality, is components set up using state variables that will be filled by the returns of promises. If a component is expecting an array of objects with certain keys, the page will break if the asynchronous response from the promise doesn’t come back in time. The solution to this is to set a default value to your state variable so that the component will have at least something functional it can put out until the promise returns. I like to use something like “content loading.”

So there you have it! Fetching, promises, and a couple common issues thereof. Come back next week when we dive back into the world of data structures and algorithms.