Month: July 2021

Go and Fetch

When I first started coding in HTML, HTML itself was a baby. This was about a year before Java, JavaScript, Ruby. All I could really do with it was play around, and my friends and I played around quite a bit in our lunch hour at school in the computer lab. As web 1.0 took shape, we coded up fan pages for the television shows and books we enjoyed, informational pages about obscure Welsh towns with really long names, individual pages for ourselves mostly, I think, for college applications. I remember coding and archive of a group story written via listserv, using small awkwardly rendered images to show who had written what and having a very neat but very ugly menu on one side of the page. It was a simpler time.

Now it’s a somewhat intimidating number of years later, and the web is very different. I’m writing this on the web, for example. I’m writing this in a word processor in a web browser via a dictation program that also interacts with the web browser. The dictation program existed back then, it was called Dragon Dictate, but the browser I’m writing on did not exist and the company that maintains it didn’t even exist for the first couple of years I was tooling around on the web. It’s an interesting world to look at having been poking around at the edges of it at the beginning, and now finally expanding my knowledge of it into things like asynchronous procedure and creating webpages that have a front-and a back-end.

Fetch (and Go)

AJAX stands for Asynchronous JavaScript And XML. It encompasses the asynchronous procedure that allows pages to load with the perception of simultaneity from the user point of view. Typically the first things that render are the styling elements involving HTML and CSS. The HTML might render the static elements either for general background information purposes or for simple styling, and as it states in the name the CSS is the styling of the page. After these initial simple elements that do not require any interaction or resolution to display, the fetch() protocol can begin.

The first part of the fetch() protocol is the request. A fetch request is a global method that acts on the window object and returns a promise object. A promise object exists in one of three states, much like a token in a Go game. Instead of alive, dead, or unsettled the promise object exists in a state of fulfilled, rejected, or pending. Once the promise object is successfully returned, rather than in the state of pending, the functions attached to it can then be performed. For the purposes of this explanation I also use the Go analogy because when a promise object is in either a fulfilled or a rejected state, it is said to be “settled”. It may also be termed “resolved”.

In the game of Go, a stone or group of stones is said to be alive if the player can connected to other friendly stones around the board. A stone or group of stones is said to be dead if it can be immediately captured. In the same way if the promise object is returned in a state of fulfilled, certain functions can subsequently be called and the intended course of the website can continue. If the promise object is returned in the state of rejected, other functions are called and usually the intended course of the website is halted so that the errors can be corrected. The functions are chained to the fetch request by a series of commands using .then. Because these functions are chained, each function can only be called and begin operation when the previous function has three settled to a state of alive, or fulfilled. Otherwise the function must be settled into a state of dead, or rejected, and errors must be fixed (or the board wiped clean) before the function chain can continue.

Like a chain of stones, each successive element is connected to the previous one. So in the typical example

A fetch made of Go.

the initial fetch() refers to a URL, which encompasses some data. The data reappears in the first .then call, assuming that first promise object is returned alive/fulfilled, and can be named pretty much anything although in this case and in standard format is usually called something like “response” or “res”. The function within the first .then call returns the response data converted into json data. The next .then call in the chain contains another function which manipulates the json data in some way, and if we needed to manipulate the returned result of that function (or set of functions), we could add another .then call, and so on. By usual practice, at the end of all of these comes the .catch call, which handles any dead/rejected promise objects. Since the rejected promise objects are now captured and can no longer be connected around the board, they must be resolved within the catch call. Having done that, as I understand it, other stones can then move around the board meeting that other functions can be called after the .catch call. But at the moment that’s a bit more advanced than my current experience has me comfortable with.

Project SEEDs

Every year since we moved to the house we currently live in I’ve had some sort of a garden. In the last couple of years, what with everything that’s happened, my garden has expanded quite a bit. So when it came to the JavaScript project it seemed like a good place to create a tracker for germination rates of every plant I tried to grow from seed.

I didn’t need a complex set of associations for this. I had Plant models, representing the general details of each type of plant I was trying to grow, and I had Pod models, representing the details of each seed or set of seeds that I planted. A pod doesn’t necessarily have to be an individual seed planted, a pod is any block of seeds that is planted in the same unit with the same conditions. I use this word because when I started growing things from seed I used little peat pods and the specially formed Styrofoam tray that came with them. Currently I use recycled plastic six packs in the same sort of tray, and since each pack is subject to the same conditions I call each pack a pod. Each of these models comes with several different attributes, as there are many conditions that can affect the growing of a plant from seed.

As far as the functions went, I knew that I would want a read function, a write function, and an update function. Read and write functions obviously to create new pods, but also an update function so I could update each pod with the germination rate. If I planted six Coyote Tomato seeds, and only four germinated, I would want to update the record with that number. It’s a simple application, but with only three A J A X calls I can keep track of the conditions in which I plant my seeds, how many of them germinate under each set of conditions, and I can see whether a plant germinates more readily on a seedling rack under artificial light or in natural sunlight.

Although the project was fairly straightforward given the material I had learned already, it was a good exercise in programming for functionality, for usefulness towards a users end goal, and frankly it was a good exercise in patience while debugging. I went through several versions of the associations before I settled on the most simple turning out to be the most practical. Once I had the associations down I had to figure out the attributes, which I knew were going to be numerous to begin with because there are obviously a lot of growing conditions that can be either created or considered. Handling a lot of attributes was all right on the back end, but on the front end it required a lot of consideration as to how I wanted to format it, where the information came from, how I needed to format it so that it could be read properly, etc. And of course, this led to the exercise in patience in debugging. Several times, various errors kicked up because I had forgotten to include an attribute, or had forgotten to format the association correctly, or had forgotten that a particular attribute was based on the association and therefore needed to be formatted differently than a plain old attribute. For example, each pod does not have a specific name in and of itself. It takes its name from the plant with which it is associated. And I have considered changing this, so that each pod can have its own name and be distinguished more readily from other pods, such as being able to call one pod San Marzano Tomato Outside, and then calling another pod San Marzano Tomato – Seedlings Rack. This might be something that I change in a future version, but at the moment each pod still takes its name from the plant.

I also had a small bit of trouble when it came to creating the edit function. The way in which I was taught through videos and walk-throughs to create the edit function did not work for either the version I was using, or for some reason I haven’t yet figured out. This came into play when creating the render function: I could not simply write the HTML code and return it, rather I had to create it via JavaScript and append it to the appropriate parent element. Then, because I was doing this in a different way than the walk-through, I had to pay special attention to each element in the HTML and connect it to each element of the edit function in the JavaScript. There were a lot of times when I had to go back, either undo the last several commands I had written or look over the last several commands line by line, see where I had gone wrong, and whether or not the changes I had made were the cause of the application not functioning as I wanted it to (or at all) or if the changes were working but I had failed to do something or if I had done something else incorrectly. It was all very complicated and, again, a good lesson in patience in debugging.

This is the first application project I have created in this boot camp that I feel is pretty much ready as intended for deployment right when I have finished it. I do still have stretch goals, and I would like to implement them, but the overall goal of being able to track germination rates under certain conditions for planting from seed is achieved. The application works. As a programmer I’m very pleased with what I’ve created, and as a gardener too.