Final Lessons in Bootcamp
React has evolved considerably since Spring 2020 when I began my program at Flatiron School. I had already completed several tutorials on my own (Udemy, etc.) when I began the React module at Flatiron. I hadn’t worked with 2 separate repositories for React, so I coded through a series of Learn Instruct videos where I needed to occasionally stop to address some errors related to outdated versions in order to view the working project.
As I type this, React 18 is the new baby. Class components are less emphasized. Hooks, which were already popular, are now ubiquitous. Embracing both older and newer processes presented some learning issues.
For my final project at Flatiron School, I had the idea of a lucky number picker. I began that project, but set it aside for something more business oriented. I was laid off at the start of the pandemic, and the stress of landing substantial work was taking personal toll on me and everyone in my household. I figured that a business registry would be stronger on my resume.
That larger project turned out to be an error in judgement. I wanted to begin using some older methods, then bring in updates with notes. I noticed a number of changes between older and newer versions of React, React Router, and Redux Toolkit. I ended up with some very ugly errors involving dependencies. I lost a significant amount of precious time.
This is a valuable takeaway for any bootcamp student: K.I.S.S. That stands for Keep It Simple Stupid, because your bootcamp time is short and your goal is to pass.
I set the business registry aside to dedicate more time to it after Flatiron. I then resumed the lucky numbers project. I chose Semantic UI for styling instead of Bootstrap. My biggest challenges were in rendering, whether it was retrieving from JSON, state, or localStorage.
My project relied heavily upon localStorage: The User enters their email and username so that a record may be created for them and their number selections. Upon save, that person’s username is added to the roster of Users and User ID is held in localStorage. As the User initiates a new Round, a game title is entered, 6 numbers are selected belonging to that User and localStorage is tapped, tying that User’s ID to the Round being entered and saved. That Round of numbers is added to the roster of Rounds.
Numbers were selected using a random number generator, which is a stand alone independent state component. While this could be connected to each input field with a bit more code, there is value to having a User spend more interaction time with a web page. It also allows the User to hit the button again if they want something different.
Upon save, the numbers are stored to PostgreSQL database via a separate Rails backend repository holding all User-to-Round relationship logic, as well as routes.
Although I was technically done, further manipulation was needed to pull individual results for our User to easily see, making our app more personalized. Here is where I had difficulty as to which path to take, and syntax. Do I run another fetch request to the backend? Do I grab again from localStorage, which I set by following the same procedure for Round ID as I had already done for User ID?
Both User and Round were already in Redux state. We could not simply grab the last Round, because perhaps a User may enter their credentials but stop before actually saving a Round. We needed the last Round played belonging to the User that played it.
In presenting results, localStorage was tapped to render the User’s last played Round and also that individual’s username to wish them good luck. These were rendered using mapStateToProps, and mapDispatchToProps to call the action and dispatch.
Reflecting on all this, React projects can be structured using separate folders for Actions and Reducers, or components can hold their own actions and related code. That’s the wild world of React. Learning brings clarity. Keep it going.
