In-Browser Persistence Using Vanilla JavaScript: How I Completed Flatiron’s First Project, Part 2
Part 2: The Complete Record
Web App URL: https://make-your-rate.netlify.app/
Video Walk Through: https://www.loom.com/share/7e80c5e16beb4f5da5722b1e10355ab1
(Extended) Executive Summary (Part 1): https://jeremiah-tabb.medium.com/in-browser-persistence-using-vanilla-javascript-how-i-completed-flatirons-first-project-part-1-90adcf7b367f
How I Did the Project:
The zeroth step that I took was to have read or worked all of Flatiron’s assigned material before this project. When I could not work all the solutions myself at least I found them and ran them on my computer and submitted them with proper attribution. Reading all the material and looking at all the solutions gave me the capability to meet all the project requirements and to make headway in completing one version of this assignment’s stretch goal.
After getting the assignment, my first step was to read it. The assignment had us build a single-page web application based on HTML, CSS, and JavaScript that accessed a public API of our choice. The webpage required some sort of user activity, an example of which would be a like button. The interactive web page changes did not need to persist after loading the page. There were no pre-defined stretch goals for the project, but a future version of the project available on git hub had one calling for the setup of a JSON server to persist the app’s interactivity. The user interactivity requirement was also a little harder and more explicitly defined: it needed to incorporate at least three separate event listeners. The assigned version of the project was presented in Canvas but the future version of it was easy to get to because a link was provided to it in the Canvas version. I decided to gear my project to the future version of the assignment, which included all of the requirements of the current version of the assignment.
Before I had read the assignment, I had selected an API to use, which might have been a mistake. But a factor that mitigated this potential error was that I chose it so that I was able to easily make fetch requests with it. I also chose it to be flexible enough so that I could get it to do EVERYTHING or almost everything that I wanted it to do. However, ultimately, I wanted to make my project customer-centric. That customer had to be the Flatiron School who created and assigned the project.
After I had read the project and attended the first lecture associated with it, I learned that the primary focus was to have the MVP (minimum viable product) finished by Wednesday (it was assigned on Monday and due on Sunday night). So, I aimed to have my MVP done by Wednesday using the technologies that they had taught to us.
The hardest part at this point was to separate what I wanted to do from what the customer wanted of me. I wanted to have multiple pull-down menus to explore the quotes by their author and theme. I also wanted to display multiple non-repeating quotes on a page randomized by quote. As I started to sketch these features down, I quickly realized that what I wanted to do were things that I didn’t know how to do yet and these things were way more than what was the MVP requirement. So, I kept eliminating features until I got down to a minimum of four event listeners. Two of them to page through the results and two of them to rate each quote. I could have easily taken that down to three event listeners by changing the plus and minus rating buttons to a single like button, but the three event listeners that the project required was a minimum, not a maximum. I decided on a paging system that we had been taught before and then I went to work on it. I sent it to my instructors on Wednesday morning and I knew that if I didn’t struggle to remove features from my MVP, I wouldn’t have been able to make that preliminary deadline. Taking my own desires out of the project (or at least putting them behind the customer’s desires) allowed me to change my MVP such that I could get it into the customer early so as to get more feedback from them as to how I should move the project forward.
After seeing my MVP my instructors told me that I should host my project on Netlify and work on some of my stretch goals for the assignment. My goals at that point were to improve the styling of the web app by introducing persistence to it. I communicated my desire to make my project look better and they gave me some resources and taught us how to improve website styling in class. I implemented those suggestions.
My other stretch goal was to introduce persistence to the app. This was beyond the scope of the class at this point which is why this stretch goal wasn’t listed in this version of the assignment. Thus, I didn’t ask my instructions how to do this but instead thought that I could give the user a feeling of persistence by saving their choices to an unseen data div element that I defined in the HTML file and also by using the dataset property of the body element in this file. Although I hadn’t seen these elements used in the same way that I intended to use them, I got this idea by remembering something that one of the instructors said in class and by reading other peoples’ solutions to the regular homework assignments.
It turned out that I was able to give the user the illusion of persistence while they were using my app. As long as they did not refresh the page, the app remembered the rating for each quote they chose to write. The user could then select the “Show My Favorites” button, at which point they would be shown another screen, with a list of all the rated quotes, listed in order of the user’s highest rating given for a quote to the lowest such rating. The optics of this newly coded screen could have been improved and a bug remained in the program as it was not showing all the quotes in the API, but the basic functionality of the web app and the newly coded in-browser persistence worked.
After I had done that, there was enough time for me to try to implement my stretch feature bug-free and improve the look of my favorites shown page. The biggest challenge for me here was to figure out why the app was showing some of the quotes and not others. I was able to narrow the problem down to the quote ID parameter of the data sent back from the server. That ID incorporated hyphens, which I believe were causing trouble when I tried to assign them to the dataset property of the document body. When I programmed the app to generate its own IDs the problem disappeared.
From that point, I had used elements from a previous assignment and what we had learned in class to improve the functionality and look at the favorites shown screen. I swapped out the unordered list with a table with buttons that controlled the ordering of the quotes within the table. With a lot of testing and bug fixes later, the program was finished as per the video linked below:
