Better Than Good Enough

For my last Flatiron project, I wanted to show the progress and growth I've made over the last five months. In the past I would make projects that met requirements and sometimes had a little flair. For the most part, I made sure I had CRUD functionality and was readable and that's basically where I stopped. But knowing that this project will be the main focus of my portfolio, not only did I want it to work, I wanted it to represent me as a creator and coder. I was able to refactor a few things using my binary search competition experience, and also use a few new techniques like the useDispatch hook and bindActionCreator (in my opinion, the easiest way to use Redux).

I met with my cohort lead halfway through project week, eager to show her my progress. She was excited, but didn't pull any punches about the things that could definitely be changed. For example, my app contains a game that consists of various rounds. My first attempt at rendering those rounds was a simple, hardcoded switch statement, changing the displayed information depending on the round. It was very clunky:

When my cohort lead expressed that it really could be more dynamic, I initially panicked. I knew I could use a for loop to cycle through the rounds, but how would I render the 'villains' and 'cards'? And how would I even change the iteration to match the current round?

The entire situation reminded me of a recent binarysearch.com challenge I completely recently. I've been trying to practice more with my algorithms and problem solving, and it was so exciting to be able to apply that logic to a real world solution.

While that progress was very representative of what I have previously learned, I was excited to display some of the new, relevant information from this section as well:
In class we were taught the use of Redux in terms of class components. We had a bonus lecture explaining hooks but our practice and lessons and labs were all using the explicit use of the lifecycle of components and connect().
Discovering { useSelector and useDispatch } seemed like a life hack. I half-expected it to be off-limits, similarly to scaffold in our third project. But it's not! It's another way to almost replicate the lifecycle, or at least almost mimic the behavior.
The useDispatch hook returns a reference to the dispatch function from the Redux store. I imported it from 'react-redux' and saved it as a variable. Easy as that, you can now dispatch actions you created, making sure you also import the action at the top. Now that you have dispatch available, simply bind it with your action using bindActionCreator,

const createUserAC = bindActionCreator(createUser, dispatch)

and that action will be implemented when you call your new variable. As with so much of React and Redux, this is not the only way to use access the store or even use hooks, but in terms of my project, it makes the most sense and, in my opinion, looks clean and readable.

In my createUser example, I have an action that looks like this:

export const createUser = (userInput) => {
return {
type: "ADD_USER",
payload: userInput
}
}

a variable that returns an object. I bound this action with the dispatch function, and when I call dispatch on it (createUserAC), the redux flow takes this object and calls the reducer:

export default function manageUser(state = {
username: "",
points: 0,
}, action) {
switch (action.type){
case 'ADD_USER':
return {
...state,
username: action.payload
}
... }

This reducer initially set the state to have an object that looked like

user = { username: "", points: 0 }

and by calling this reducer, with the information from the action, we are able to set the username in the store to our user's input.

This whole process took me over a week to fully understand, but once I could follow the flow, adding new functionality became a breeze. I was able to add 'RESET_POINTS' and 'RESET_ROUND' actions for the end of my game in minutes.

These small aspects of my project have become the focal point for me. In the past I would've been satisfied to have the game work well enough, submit the user to the backend, and shut down. But I wanted to have something exciting and fun and creative to show. I want to have a program that makes people laugh and want to keep playing and want to know more. Most importantly, I wanted to make something I would enjoy if I happened upon it somehow.
And I really did.