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

#react #beginners #productivity

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: