Over the last three weeks we learned all about React. In short, it's an interesting tool used to split a project into multiple bite sized pieces to make it more easy to individually interact with aspects of the code/design. This comes with a whole host of new issues however, as you have to learn how many of these 'components' to use, how to pass code and variables between them, and where to put your code to make it the most effective. In short, a whole host of new logic that is difficult to wrap your head around.
Links in a Chain
One of the most difficult aspects of React for me, was learning how much I needed to split my code between different components. Coming into React from a pure JS/HTML/CSS background meant that I was already more than comfortable putting every individual component onto the same page, which I admit, makes code hard to read.
Above is a very rough draft of the component tree for my phase two project. Part of this messiness comes from our initial confusion on how client side routing actually works, and part of it comes from a weak concept of what our end project would actually look like. The final component tree of our project wound up looking something like this:
A whole lot cleaner and nicer to look at. Though this final component tree doesn't manage to include the amount of times we deleted components, thinking they were unnecessary, only to bring them back with an entirely different purpose. I think working through a big project like the end of phase project was a very valuable teacher on the benefits of components, and how to create them effectively. With this skill more developed, I look forward to including it in more projects going forward.
Infinite Rendering
Another massive struggle of React for me, was learning to have JS code inside my HTML, and more importantly, when/how to have that code working. Up until this point, I never had any issues like this because a page would load its HTML, its CSS/JS, and then stop. With React, the page would constantly bounce between loading aspects of the HTML and JS, and with these two regularly calling on and altering one another, errors on load were very common.
The single biggest example of this was when I was trying to code an answer shuffler for our quiz game. All I wanted to do, was on question load, create an array with the correct and incorrect answers, shuffle it, and then have it populate the questions inputs. This was harder than it seemed.
The only way I could think of reasonably calling the function that did the above, was to have it nested within the return for the HTML. The issue came when I realized the HTML would load before function had done its job, and so the answers would be populated with blanks. I thought to get around this issue by simply using a setState. That really didn't work. Having a setState called in the HTML was causing the page to reload each time the state was set, which would cause the function to be called on again, leading to an infinite loop of renders that kept breaking our webpage. Thankfully, watching this error occurs in the thousands in my DOM, was at least humorous enough that I didn't want to throw my mac into the middle of the street. In the end, I would up using a let statement and a 'id.textcontent' to fix my problems, so at least it wound up working.
Finding Answers
My final notable React Struggle, was getting individual responses from a '.map' of our generated questions. In each '' that was mapped out, I needed to get a single answer from each of them, with a single click in their parent component. I couldn't make it so that each answer was immediately added to an array, on the off chance that someone might change their answer. This meant that on the click of the submit button in the parent component, I needed to grab an individualized answer from each of the children.
Initially I had the idea to take the id key from each individual question, name an object that, and populate that with the selected answer, and have it be overwritten with a new answer if one was selected. Then I could just grab the contents of every object named after the question ids, and I would be home free. It was then that I learned that JS has no good way to name a variable without strictly knowing the variable name, which sucked.
Eventually I came up with a solution where I had a hidden '
' element at the end of the return which had an id of the question number (something I also had to implement for this solution to work), and on answer change, that element would be populated with the chosen answer. Then on the submit event in the parent component, all I had to do was a line of 'document.getElementById('')' and push them all into an array. This had the unintended side effect of meaning that unanswered questions were automatically counted as wrong, which is nice, because I was worried about running into some 'undefined' errors.
The Project
The Phase 2 project was a really good time for me and my partners I think. We put in a lot of effort to keep organized and to split our efforts between us, playing to our strengths as much as possible. At the start of every day, we would sit together and using a Trello board, we would examine our needed work and our wanted implementations, and then we would divvy our work for the day. This kept us from repeating work, and often prevented us from working on aspects of the code that would wind up conflicting. By carefully managing our merges and our pushes, we were constantly able to keep each other on the newest version, and we never wound up losing any work, which is nice. At the end of the day, my only regret about the project was not having a little longer to work on it. While the end result was (in my opinion) pretty impressive, we did wind up dropping a number of features that I think would have been very good. If I manage to keep the motivation, I might actually do a little more work on it to include these things.
Top comments (0)