A Coding Blog Bitcoin Story #5: ‘Modaling’ in the Coding Canyon
During the coding bootcamp of last year, we dove into new topics and concepts pretty much every class period. The material and assignments were thrown at us at a frantic-like pace, which meant I never really got into a groove. Unsurprisingly, I lacked confidence all the way through.
Now, I feel like I found that groove. I’m feeling like Michael Jackson on the dance floor during the filming of one of his music videos. I’m moonwalkin’ baby! I’m moonwalkin’!
Okay, that’s a big time stretch right there. I do feel confident in my abilities, and I do feel like I “get it” now, but I wouldn’t say I have the confidence of a professional. Not by any means.
What I mean is I’m able to conceptualize and visualize how to build out parts of the application now. During the bootcamp (and even after it) I would spend hours upon hours thinking about how to build something, but remain stuck on it for what felt like an eternity. I’d be flush in the face and on the brink of a meltdown more times than I’d like to admit.
But now that I’ve honed my focus onto specific languages and concepts in a “one at a time” manner, those meltdowns have ceased to exist. This focus and dedication to the step-by-step process, combined with the actual experience of coding a challenging but achievable concept, has given me the gift of foresight. I can visualize how the next piece will fit into the ever-expanding puzzle, as well as how it will work within React’s state-based framework (which is technically a library).
And that’s exciting because React was where I really wanted to improve when I started this Yahtzee project. I definitely wanted to get comfortable with JavaScript first, but overall, becoming skilled in React was much more important to me.
What I quickly figured out as I began building the game was I would be learning both in tandem. I could add in some JavaScript-based functions, but they would still need to interact with the proper components and be triggered at the right moments. They would still need some love from React; and boy am I glad they did.
Because now I feel like I know my way around it. Adding functions, manipulating state, setting up new components, passing in props, capturing values, triggering events — that’s all a piece of cake now. I can whip those up nice and quick. With this experience, I’ve gained comfortability in React and JavaScript. and I now have a solid foundation to work off of, as I proceed to learn additional concepts going forward.
In addition, this comfortability has made reading documentation unintimidating. Previously, when looking at documentation aside from .css, I would get flustered extremely fast and my eyes would glaze over at the sight of anything unfamiliar. With my newfound confidence, that’s no longer the case. I am eager to read and learn and test out whatever I’m researching. Even going to stackoverflow.com doesn’t feel like a rigged crapshoot anymore. Now that my shaky foundation has hardened, I’m no longer afraid and intimidated by the unknown .
This became very evident as I began building out the modals for the game. It became evident because I wasn’t interested in using the code from the team-based project we worked on after the bootcamp. I did review the code we used, but I was more interested in learning why we used it, and how it compared with other techniques I reviewed on the interweb.
When I first skimmed our project’s code, I noticed we used React’s Context API. I really didn’t understand why, or what this was, so I read through the documentation on the subject (found here). What I learned was Context is used to share data that could be considered global (and this also led me to researching the global-state management library, Redux; which I plan on using at some point in order to expand my React-based knowledge).
The documentation provided a great example of using Context to change the “theme” of an application. For instance, various “themes” could be passed around to multiple components, storing the data in one particular state that could be called and altered from anywhere. I definitely saw value in this (and Redux, too).
For Yahtzee, I didn’t really feel like I needed to globally share the data and I wanted to figure out another way on my own, so I didn’t end up going that route. I will likely use it for developing different themes (one of my next tasks), but for the modals, I was going to try something else.
To start, I wanted to create two separate modals that would be used at different points in the game. I wanted a modal to pop up when a user wanted to restart (because their score was bad or something), as well as when the game ended. I decided to tackle the EndGameModal first, and I started by adding a new state variable to keep a tally on the number of “overallTurns.”
When the number of overallTurns hit 13, the modal would then pop up to display the user’s total score and ask them if they would like to play again (and reset the game), or if they would like to bask in the glory by looking at their score even longer (and not reset the game until they choose to).
To accomplish this, I incremented overallTurns by 1 each time setScoreTakingState() was called. You’ll see that with: ‘overallTurns: this.state.overallTurns + 1’
Then, after each turn, we would call the checkEndGame() function to check if the number of overallTurns was > 12.
If so, every clickable option would become disabled, and the showEndGameModal() function would be called. In the screenshot below, you’ll see this function, as well as the other functions that decide whether or not the particular modal should be displayed on the screen.
Once showEndGameModal’s state changes to true, this property is passed from <MainPageContainer> to <MainPage>, which then funnels into the <GameEndingModal> component as ‘props.showEndGameModal.’
Within the <GameEndingModal> component above, you’ll see a conditional statement that turns the modalDisplay variable into either a big blob of modal, or absolutely “null-thing” at all.
The two other important takeaways from the <GameEndingModal> component are what the Buttons do. With an onClick of the <ResetButton>, the resetGame() function is called, which closes the modal and reverts the state back to square one, so a new game can begin.
The second Button, aptly named <Button2>, triggers the dontReset() function. All that does is change the showEndGameModal’s state to false in order to close the modal. From there, a user is frozen because everything else is disabled. The only way for the user to re-enable the disabled is to:
- Click the “New Game” Button
and…
2. Confirm they would like to start a new game after the <ModalRestart> component pops up.
But before we get into that logic there, let’s move back to the MainPage, where the <RestartGame> component is found.
In the above screenshot, you’ll see 5 different props passed into the <RestartGame> component, and in the next screenshot, you’ll find the actual <RestartGame> component.
Here, you’ll see that the component returns the <ResetButton> and the ‘showModal’ variable. The <ResetButton> is the button I referred to when describing how to start a new game after a user chooses to “bask in their score longer” once the game is complete (overallTurns > 12).
Clicking of this button will change the showRestartModal’s state to true. Then depending on whether the game is under way or already over, the showModal becomes <ModalRestart> with different properties assigned to it (it really just changes in the text that is rendered).
One interesting thing to note is I didn’t include the && props.overallTurns logic in this modal’s first iteration. So when a person clicked the “New Game” button, it always asked them if they were sure they would like to do that, followed up with buttons that said “New Game” and “Keep Trying.”
Well, obviously this doesn’t make sense if the person “basked at their score a little longer” when the game had already ended, so I needed to render different text in the event it had. Thus, I added the checks and changed the text accordingly, and created a new <ModalRestart> component to pass in the different text-based properties.
This component does pretty much the same thing as the EndGameModal, but you might notice the added function at the top, called handleBackgroundClick().
The reason this function was added is to close the modal if a user clicks outside it. After all, that’s what a user expects to happen when they click outside of a modal — and you never want to disappoint the user — so I made sure I figured out a way to incorporate it.
Well, I must admit I took this code from the coding genius I previously worked with. With that said, though, I did not just plop it in there without doing my research. I did some googling and browsed through stackoverflow.com for other methods (I also could have just added the react-modals NPM package), but this one made absolute sense and seemed like the way to go once I did the research.
What this function does is compare event.target with event.currentTarget. If they are the same, the modal will close.
Well, okay, obviously, but what’s the difference between the two? What I learned is that event.target refers to the div that is clicked, whereas event.currentTarget refers to the div where the listener is located. In this case, the handleBackgroundClick() function is located in the class=“overlay” div, so if the user’s click is within that realm, the === statement will return true, and the modal will close. However, if the click is within the modal itself (and on top of the overlay div), the event.target will NOT be the “overlay” div, so the modal will not close.
After learning how it worked, I had to go with it. I did my due diligence and made sure I understood how it worked completely, so I was content with adopting it into my application even though it came from the prior project. Learning was still taking precedence over progress.
And with that, my modal task was complete. Even more importantly, the entire game was too. Without a hitch, my Yahtzee game can continuously loop and start anew. Bug-free and clean as can be.
With this success, my confidence level has increased; and along with this, I’ve developed even more of an eagerness to dive into new concepts and code them into the application. It’s pretty exciting and very satisfying to finally feel this way. The coding moonwalking moment has arrived, and it’s been a long time coming!
Thank you for reading this “Modaling in the Coding Canyon” edition of A Coding Blog Bitcoin Story.
Until next time,
Sam
