My Personal Coding Project to Learn ReactJS
Explore the docs »
Report Issues
·
Submit Improvements
Table of Contents
Learning JavaScript algorithms and data structures was very fun for me, but once I got to learning about libraries and frameworks, I was having trouble conceptualizing how or why a library like React was supposed to help in practical cases. So, I thought “Why not try and actually use it in a real-life project?”. I was thinking of possible projects and eventually landed on coding a blackjack game since that’s a game that’s always interested me ever since I watched the movie, “21”.
After pinpointing what from React specifically gave me trouble conceptualizing, I made sure to make an active effort to at least learn components, jsx, classes, and states. More specifically, their practical uses and how they fit and work together.
- Browsed many different blackjack games written in javascript
- Tried to figure out what each piece of code did and how they all fit together. (Much easier said than done)
- Looked for a Front-End Template
- Changed pieces of code to see what it did on the front-end
- Compared how Reactjs achieves the same thing
- Took my customized front-end template and converted it into ReactJS
- Briefly planned file structure
- From looking at some of the bigger and more sophisticated open-source projects on github, I knew I wanted many simple components that generally serve one purpose. (Just looked neat and organized like that)
- Started on the pre-game page
- I planned to have two pages (one for pre-game and one for the actual game), so I started thinking about what I needed on the pre-game page
- Incorporate states
- Having trouble on sharing variables in separate components in the pre-game page made me realize this is what state is for
- I initially tried using class components and constantly passing down props
- Eventually, I learned about hooks (specifically, useContext and useEffect)
- And eventually made everything into functional components with hooks
- Worked on the game page
- For guidance, I looked at different blackjack games written in js and how they wrote their render components
- This helped me get an idea of what functions and states I would need for each component
- Organized files
- Continued splitting components as much as possible to make them easier to identify in debugging
In the outermost layer, the whole app is essentially wrapped in a global context provider so that any child components can access the global state without having to manually pass them down each time. The next layer inside is the start page (which, more or so, serves as a convenient container for the header and two “pages” of bases)
At the surface, the pre-game base takes 3 functional components to handle updating current balance, placing bets, and displaying an instructional message. The only sigificant component it has is in placeBet.js. When you place a bet, it goes through some conditionals to make sure you have enough in your balance and to make sure that the bet is an integer. In addition, if the global deck has less than 10 cards, it'll create a new deck by calling generateDeck(). Finally, it'll call dealCards() to deal one card to the dealer and two to the player.
The game base essentially displays 3 functional components like the pre-game base, but since all the game logic is handled here, the game base components go a little deeper than pre-game’s. One of the two main components that the game utilizes is from cardDisplay.js. This file primarily handles retrieving the current cards of both players and rendering the cards with templates from the createCards.js file.
The other main game component is in the gameButtons.js file. This file essentially renders a start new game button or hit and stand buttons based on the game state.
For the hit button, it first goes through some sanity checks. Then it calls getRandomCard() and adds the returned card to the global player cards array. It then calls getCount() to update the count based on the cards in the players hand. And if the player’s count is over 21, it subtracts the bet from the balance, resets the player’s hand, and ends the game. If not, the player is able to hit or stand with their new hand.
If the player stands, the dealer will keep calling dealerDraw() and update its hand and count until the dealer’s count is greater than the player’s count. If the dealer’s count is greater than 21, the game state is updated to reflect the correct changes. If neither player nor dealer bust, it calls getWinner() and whoever has the higher count is deemed the winner. If not, it’s a push and the balance remains unchanged.
NOTE: If a player stands with a count less than 11, “dealer.count < 12” ensures that the dealer will always “draw” at least one card (equivalent to the dealer flipping their second card in real-life).
As I got more knowledgeable during the course of this project, I became more aware of the inefficiencies of my project. Before I was even able to just get a working app, I kept changing the architecture of my project. And when I’m just trying to learn about how things work in general, changing the foundation and logic I started my project with just lead to more confusion and inconsistencies (even if they did make it more efficient and organized). Even though this was a project I did myself, it looks like it was as if multiple people were forced to make a project together with the added challenge of not being able to communicate with each other.
Pseudocode would have saved me a lot of time because I would think of a feature or component to add, and before really thinking about what exactly I would need in this function, I would be too eager to start coding and lead myself down the wrong path. To help visualize, it’s like if I were lost in the woods and even though I know I have a compass in my bag, I just start walking in a random direction without even bothering to look for it just because I’m that excited about walking.
Commenting would’ve helped jog my memory on what each component does because every time I opened up my project to work on it, it would to take a couple minutes of just staring at my code for the lightbulb in my brain to click on and remember what I’m looking at and what I needed to work on. And now that I'm currently working on this, it also would have helped out tremendously with writing this documentation because it’s been a while since I last worked on this. I had to really dig deep in my memory to try and remember what my thought process was during that time.
I was aware of the importance of version control even before this project, but when it came to actually try and set up git, I was confused, and quite frankly, intimidated. During this project, I almost ran out of disk space because I created at least 6 copies of this project because I kept thinking of different ways to design this project.
This kind of goes hand in hand with pre-planning, but now that I know a little more about standard design patterns, I want to try and plan what type of structure I would need based on the outline of my project.
Unlike my previous lesson, I need to try and separate my CSS files because I found navigating my single CSS file quite tedious and confusing. I plan on only keeping global styles like fonts and general HTML tags in the main CSS file and place the other CSS files in the directories that they're used.