Flatiron School Software Engineering Phase 1 Complete! — My Project
After an intense 3 weeks (technically 4 weeks thanks to the holiday break) I have successfully completed Phase 1 of Flatiron School’s Software Engineering Live program. I will be reflecting on some of my thoughts on the AWESOME experience thus far in a separate post, but first I wanted to share my Phase 1 Project.
Phase 1 revolved around Javascript, building upon the HTML and CSS we learned during the Pre-Work curriculum that we were asked to complete prior to starting. Our assignment was to develop our first web-based app from pitch to development to presentation.
My partner, Gian, and I decided to develop an app utilizing recipe APIs (in this instance an online database that we can get data from). After exploring some of the public APIs that are available (that do not require keys or have CORS protections which was a challenge we ran into with our initial API) we decided to use TheMealDB.com which is a open, crowd-sourced database of recipes from around the world.
After deciding on which API to use, we needed to have a user and a problem to solve. After brainstorming, we both shared frustrations with trying to decide what to cook with friends. We also both had a tendency to decide what to cook based on what proteins we had readily available to us. Given the API and our Javascript/HTML/CSS knowledge, the solution seemed doable!
Starting with the HTML, we were able to build the basic skeleton for our app. The CSS took that basic skeleton and added skin to make the app easier to interact with for the user (a special thanks to Coolors.co for their color scheme generator!). The Javascript added the muscles to give the app functionality.
Here is how the app looks when it is initialized:
…And here is how it fully function!
As I will speak more about in my reflection post, despite completing Phase 1, I am hardly a Javascript expert, but Gian and I were able to overcome a few specific challenges and learned to appreciate Javascript even more.
Our first major challenge was with our thumbnail bar, or the recipeBar as we referred to it.
In order to populate the recipeBar, we fetched specific data from theMealDB.com based on which of the five proteins (Pork/Salmon/Beef/Chicken/Tofu) the user clicked on. The challenge we ran into was after populating the recipeBar, upon clicking another protein rather than clearing out the bar and replacing it with different thumbnail images, more images were added, quickly leaving the user with a bloated and overpopulated recipeBar. After trying to manipulate different parts of that recipeBar code, we .finally came up with a solution. We .finally used .finally (all pun intended).
.finally is a Javascript method that works with fetching. It is very common to use .fetch and to add additional functions to the fetch with .then. Basically, after making a request to access data from the database, .then allows the data to be used in specific ways. We were successful in using .fetch to get the data which allowed recipeBar to continually populate. The code was only doing what we asked it to, only too well!
By using .finally we added a final step to our fetch. .finally waits for the rest of the fetch to complete (whether successful or not) to run.
In this specific instance, we waited for the fetch to get the data and populate recipeBar, and then finally (no need for a period there) run another function that would clear out recipeBar. This would not ever be necessary if the user only clicked on one protein, but more for if the user wanted to click on another protein. We finally found a solution to not overpopulating the recipeBar (because let’s be honest, who really likes a bar that is too packed).
Another challenge was with our recipe Ingredient List, or recipeIngredient as we called it.
theMealDB.com (like all API databases) is only as good as the data that is entered in it. Because it is open and crowd-sourced, the database is dependent on how people enter the data. The data is structured to have 20 potential ingredients and 20 potential ingredient measurements, but not all recipes had 20 ingredients. This would result in the container around the recipeIngredient not sizing dynamically, meaning the container was often too tall because the container was automatically sizing itself for 20 ingredients even though 20 ingredients might not be in the container. The data had to be filtered…
Enter .filter which is a method that filters for specific conditions that are set in the code. But what conditions do we need? After testing through many recipes in the database we found not all recipes were entered with the same data for NOT having ingredients. Some recipes did not enter any information for ingredients. Other were left with “” and even others with “ ” (one empty space). We had to do a lot of filtering! Fortunately .filter allow you to set multiple conditions at once essentially having multiple filters at once.
In the above code, the conditions set were to filter out for anything that NOT null, NOT “”, and NOT “ ”. Thanks to this filter, the container around recipeList would size itself based on how many ingredients each individual recipe had.
There were certainly other challenges as well, but these were the two that we were the proudest of overcoming. By overcoming these (thank you Google!!!), we learned the most about how to really use Javascript to build an app that user friendly and dynamic, and successfully solves a specific problem.
In the future I hope to add functionality to allow the user to make a shopping list with the ingredients, being able to mark a checkbox if they already have that ingredient so it will not be included in a shopping list they can bring with them to the market. But in the meantime, I am very pleased with the app Gian and I built.
I’ve come a LONG way from my first static Geocities and Angelfire webpages!
Check back this week for my reflections on Phase 1!
