Forem: samity89

making a single-page React application from scratch and my plan of attack

samity89 — Mon, 28 Nov 2022 22:14:38 +0000

So the time for my Phase-2 project at FlatIron School's boot-camp for Software Engineering was upon me, and I was dreading it. I have never been the best student, and my time learning software engineering has been nothing but the same. My confidence in my understanding of the material was shaky; my study habits had done nothing to bolster this. I want to show you how a good plan of attack will guide you through your process and allow to break a larger problem into more digestible chucks that won't be so upsetting to your stomach.

For my project, I decided on making a rudimentary website for the local bar I work at (shout outs to Monterey Pub in Pittsburgh.) I had my idea, but understanding the information flow is essential to properly create a single-page React application. I decided to draw the diagram above. I wanted to see Parent components and their corresponding children so I knew where to put the state for the components that relied on my API (or in this instance, my json database.) After drawing the diagram, the answer was obvious. The App component was parent to all other components and therefore could pass all of the state information wherever necessary. From there, it was breaking down what I needed each component to do. I added each of these deliverables to the components in my diagram to more easily visualize my list of problems, while also making sure each of the requirements for my project was met. As I stated in my previous blog, coding is ultimately problem solving.

I went on to create the skeleton for project. The App component being a parent to the Food, Drinks, Home, and Contact Us components. I used client-side routing to allow the user to render all of the components from a single page using specific addresses or the NavBar component. I began writing my Fetch Requests, passing down the acquired state as props to the proper components. My code was getting a little wet though. Having all this code for rendering cards directly in the component was getting to be too much. I went back to the diagram to visualize drying it up.

One of the biggest benefits of React is how easy it is break down into smaller components. It allowed me to mentally divide each of my problems a little more clearly. By each of my components responsible for rendering menu information having their own children to actually execute this functionality my code was all dry again.

I ran into a problem with the required post or patch request for the project. This is the Post request I initially wrote, but I kept getting a 500 error. I could not figure it out why.

 function handleFormSubmit (event) {
    event.preventDefault()
    fetch("http://localhost:3001/users", {
      method: "POST",
      headers: {"Content-Type": "application/json"},
      body: JSON.stringify(
        {
        "username": formData.username,
        "userEmail": formData.userEmail
        })
      })
    .then((response) => response.json())
    .then((newUser) => handleAddUser(newUser))
    setFormData(initializeForm)
  }

I double and triple checked my syntax. I was at a loss and panicking. As it is right now as I scramble to write this blog, I was scrambling to finish the application. After much digging, I finally realized it was a flaw in my data structure.

  "users": [
    {
      "username": "Vila la Bob",
      "userEmail": "homeagain@gmail.com"
    },
    {
      "username": "Buzz",
      "userEmail": "infinity@andbeyond.com"
    }
  ]
}

These were the mock users I had included in the database to insure both the post request and my user render functions worked properly. Notice something missing? They lacked the very important key, "id." The post request failed, because an inherent attribute of the script wants to assign an "id" key to every new object. The objects currently present in the array lacked this "id" key, so the fetch post request had no reference to assign the new object an "id." When I was creating this database for the sake of project, I hadn't included an "id" key on any of the data because I did not realize its importance in fetch requests. Be mindful of this when creating databases, and as a general rule of thumb, always include an "id" key in any object present in a JSON or API database. I only figured this out through the most basic way.. the stack trace. Read your errors folks. I didn't see it at first, it was server side. The browser console did not specify what was happening. Only when reading the server side error in Visual Studio Code terminal did I see it was not able to assign an "id." I could have saved myself so much anxiety.

Leaving this project there are three important things I can say I have taken away:

The importance of well defined plan, even if you end up changing it
Structure your databases properly
Troubleshooting skills are king. Learn them all. Debug, read, log.

the beginning of my coding journey

samity89 — Sun, 11 Sep 2022 17:19:58 +0000

Throughout the start of my coding quest, there have been many growing pains. Some of these pains relate to my own person; such as teaching myself how to be a student after being out of school for thirteen years. Others, as expected, come from the difficulty of learning a new language. Like my native tongue of English, JavaScript has layers of nuance and exceptions to rules. In this blog today I'd like to outline some of these niche cases that tripped me up when creating my very first frontend web application, for Phase-1 of the online software engineering program at Flatiron School.

First, I'd like to address working with asynchronous functionality, in this case a fetch request.

let fighterArray = []
console.log(fighterArray);
document.addEventListener("DOMContentLoaded", () => {
    alert("RNGesus will... CHOOSE YOUR FIGHTER!!")
    grabFighters()
    addFightersToArray()
    document.querySelector("#reset").addEventListener("click", () => {
        document.getElementById("character-select").innerHTML = "";
        fighterArray.length = 0
        console.log(fighterArray);
        grabFighters()
        addFightersToArray()
        console.log(fighterArray);
    })
    document.querySelector("#randomize").addEventListener("click", () => {
        console.log("random")
    })
    document.getElementById("theme-dropdown").addEventListener("change", (e) => {
        if (e.target.value === "dark") {
            document.querySelector("link[href='light.css']").href = "dark.css";
        }
        else {
            document.querySelector("link[href='dark.css']").href = "light.css"
        }
        }
    )
    }    
);

function grabFighters() {
    fetch("http://localhost:3000/fighters")
    .then(response => response.json())
    .then(data => data.forEach(fighter => showFighters(fighter)))
};

function addFightersToArray() {
    fetch("http://localhost:3000/fighters")
    .then(response => response.json())
    .then(data => data.forEach(fighter => fighterArray.push(fighter.id)))
};

Over the course of writing this code, I was using console.log to troubleshoot that elements were being properly selected and to ascertain if my fighterArray was being emptied and restored properly.

    document.querySelector("#reset").addEventListener("click", () => {
        document.getElementById("character-select").innerHTML = "";
        fighterArray.length = 0
        console.log(fighterArray);
        grabFighters()
        addFightersToArray()
        console.log(fighterArray);

The code above contains a console.log of the fighterArray after setting the length of the fighterArray to 0. I expected this console.log to return an empty array with a length of 0. However, this console.log always returned a length of 19, which is the number of values that should be present after addFightersToArray is called. Ultimately, the EventListener was functioning properly, but I needed to comprehend why that first console.log didn't return what I expected. Upon teaching myself to use debugging tools in Chrome, I realized its due to the asynchronous nature of the functions called using fetch. This shows while console.log is a very strong tool while writing code and troubleshooting, there are some inherent flaws in using it solely.

Another one of my more perplexing issues came up a little later in the process. While I was able to find a workaround, a decision I made much earlier in my coding led to an issues properly selecting items later on down the line.

{
"id": 7,
"name": "Arya Stark",
"image": "https://cdn.multiversus.com/roster/arya-t.webp"
}
-------------
function addFightersToArray() {
    fetch("http://localhost:3000/fighters")
    .then(response => response.json())
    .then(data => data.forEach(fighter => fighterArray.push(fighter.name)))
};

Above is an example of an object contained within .json that I fetched during addFightersToArray. While it was not technically a mistake, my choice to push only fighter.name rather than the whole object of fighter ended up handcuffing me a little later. Only pushing fighter.name to the array resulted in me having to write an additional function to identify the card the information was present in. Many of the fighter names contained spaces, so when I tried assigning them as the IDs of their corresponding cards they could not be found using interpolation. Yes, I found out during this project that IDs with spaces while technically valid cause many hiccups when trying to select them. I have learned that the more complex the data source, the more easily it is worked with. If I had pushed the entire object in the array I could have easily added clear targets for selection.

I'd like to close with some general statements and anecdotes regarding my experience thus far while learning JavaScript.

Coding is problem solving. Having a routine on breaking down and analyzing the problem before writing any code is conducive to success.
Syntax was my number one issue when getting tripped out. Did you close the parenthesis? Did you omit a comma? While VSS holds your hand as much as possible these are still very easy mistakes to make.
Be very mindful of the scope of your variable/constants/functions. While it is best practice to make these as globally scoped as possible, there are going to some exceptions to this. In particular, if your page doesn't function until DOM content is loaded. The asynchronous nature of this EventListener means they variables need to be accessed after your script fully loads.
Any instance of code used multiple times over the course of your script should be converted into a helper function of some sort. This will allow you to both streamline the code and for it to be cleaner and more easily readable.
Define variables/constants/function with names that pertain to their data or functionality. This too will present a more understandable code for your own troubleshooting or for others who are dissecting your code.
There are a thousand ways to skin a cat. In other words, there are going to several ways to code whatever functionality you seek. Just because someone else took a different approach does not mean you are incorrect. It most likely mean you conceived the problem differently.
Don't be afraid to ask peers and instructors for assistance. No one would be where they are in life without the help of others.
Most importantly, in the words of a 2014 YouTube viral video that resonate in my head to this day: "Google that shit." Can't wrap your head around a problem? Chances are someone had that same issue long before you and there's a post on StackOverflow.
Don't be discouraged if concepts don't stick immediately, if this old dog can learn new tricks, so can you!

Cheers to a stressful yet enlightening start on my arduous journey!