We were pleased to have Tyler McGinnis on React Wednesday to help out with some live coding exercises. The Digital Primates crew are big fans of Tyler and his work. Tyler’s courses are part of our training program for technical staff. In fact, even though I’m the “marketing person”, I am going through his courses right now.
If you want to learn modern JavaScript or React in a video course format, check out UI.dev. You’ll find courses on:
- Modern JavaScript
- TypeScript
- React
- React Hooks
- Redux
- React Router and other specialized topics.
The goal of the show was to have one person write code, and the others ask questions, shoot holes, or heckle. Mike Labriola used his blackjack simulation code from DevReach 2020 and TJ, Tyler, and I spectated and chimed in from time to time.
A Blackjack game has business logic matching the rules of the game. Tyler wasn’t familiar with the intricacies, so we walked through the rules, and the set-up code Mike prepared. Mike left some of the code out of the project so he could add it back in while we discussed.
Does Functional Programming Result in Cleaner or More Complex Code?
The first exercise for the team was to wire up user actions. In the Blackjack application, there are buttons for the user to indicate their choice at each stage of the game. These buttons dispatch messages that are caught by other parts of the system, triggering code execution. Rather than use a simple value or inline object for the dispatch argument, Mike passed in a function. You can think of this function as a useReducerReducer.
This idea generated some commentary from TJ about readability and being overly complex. His point was the indirection of the function as an argument made it harder to follow the logic of the code. Mike pointed out that using the function in this case allowed for the code to point to the object shape that would be returned, giving the necessary context to the reader. Naturally, there are pros and cons to both methods, and not all reducer calls need functions as arguments, but there are cares where a bit of indirection in one area brings benefits in readability and maintainability.
In this case, because the passed functions help to shape the state, the code is a bit cleaner because the functions are passed as a higher-level abstraction than the normal ways of passing in strings or object literals.
Using Recursion for Fun and Profit
A player may opt to ‘stand’ once they believe they have accumulated the best hand of cards. Upon electing to stand, it’s now the turn of the next player, or if there are no more players, the dealer. Mike implemented the ‘stand’ function using recursion. The commentary and discussion around readability and the good moments to use recursion is an interesting one. Basically, the next operations required by the business rules all operated on the same set of variables and needed to continue until all rules were satisfied. By choosing recursion, the code stayed super tight, continuing to iterate down the various player hands and dealer hand until all the work was done. Friendly warning, write your base case first, else face the wrath of Stack Overflow (The out of memory kind, not the place you copy-paste code from)!
Solve your Current Problems not Your Future Problems
During a conversation on the differences between demo code and production code, Tyler pointed out it’s best to initially solve only the current problems and not the future ones. This leads into a cleaner understanding of the problem space. Once the code is working and handles the current problems, it’s then more refactorable into resilient code because there is less code to trip over.
This point is a very important one, and one that often confuses junior developers. It’s easy to see possibilities and want to defend against undesirable actions, or even make room for potential future actions. That said, writing code is analogous to pouring concrete, once in place, it’s very hard to remove.
Final Thoughts
There is something satisfying about watching someone else write code. I find I can step away from thinking about syntax, and typos, and more on the problem at hand. There are even whole strategies about making this the practice for how teams write code. I’m not ready to go that far, but I did learn a lot from Tyler, Mike, and TJ.
If you like this kind of thing, check out more React Wednesday episodes, watch show recordings, and stay in touch with me and TJ.
