A Coding Blog Bitcoin Story #2: Softening the Hardcode and more MoneyButton API talk
Coding is bipolar. It makes you feel like you’re a total dunce one minute; then it makes you feel like you’re a wise wizard the next. It’s enough to drive a person insane…
Luckily for me, I’m on the wizard end of the spectrum right now. I feel great about what I just coded, and I’m looking forward to sharing it with you.
In the last blog post, I mentioned that the <table rows> for the Yahtzee game were hardcoded into the app, and I needed to refactor them so I could dry up my code while passing in properties (props) into each row. Well, I accomplished that, and more.
On this 2nd iteration, each table row turned into its own component. Then depending on the properties passed into it, the following would be returned and displayed on the page:
You can see the properties passed in, but you might notice that they’re missing the props in front of the variable name. The reason why is because those props were converted into variables beforehand, so the code would look cleaner. You can see that with the first line of code included below.
You’ll notice other variables declared without a value, and the value-declared bottomBorder as well (which should have been a ‘const’ rather than a ‘let,’ but I didn’t catch that until afterwards, and it really doesn’t make much of a difference anyway.)
You’ll also notice the rowType property… Which is: the most important part of the component. Which is: Why I’m feeling like a coding wizard right now.
Depending on what rowType is passed into each <TableRow> component, there will be a difference in what is rendered on the page. Since there were four different types of rows, four different scenarios needed to be coded in.
The first and last rows were entirely unique so they received their own customization. Most rows included a selectable *radio* button so they got their own version as well; and the remaining batch of rows were sick of music and don’t want to listen to the radio anymore, so they needed a distinct rowType of their own too.
Hence, the “labelRow”, the “noSelectionRow”, the “finalRow”, and the “everything else” row — which includes no label at all (These label-less rebels can be considered crusaders against the music industry).
You might be thinking that a switch statement would be a cleaner way to go here — and my main man Meng thought the same — so I “made the switch” and converted this lengthy if/else statement into a switch hitter. He also mentioned that switch statements should be very simple and clean, so the variable declarations (rowOneClasses, rowThreeDisplay, and so forth) needed to be turned into functions that would be called based upon the rowType property. You’ll see that in the screenshot below.
You’ll also see the formatBottom() function included in this screenshot; which adds a bottom border if the bottomBorder prop returns true. If not, it makes no alterations to the classes. Pretty simple, yet so very satisfying.
And the last <TableRow> alteration was removing the many rows repeated in the code from the first screenshot. My other main man Justin thought it would be best to clean this up too, so a “map-able” .json file was hired as the clean-up crew for this dirty job.
After the .json “array of objects” file was setup with the proper properties, I imported this file as the rowData variable, and then mapped over it to create each <TableRow>.
So fresh and so clean, clean — don’t-cha-think? I do, and because of that, I’ll likely do the same thing with the <Dice> once I get a chance. Right now, they look a lot like the first screenshot of the <TableRows>, where five <Dice> components are listed with properties passed into each. Since it’s relatively similar to the 1st <TableRow> screenshot, it’s relatively unnecessary to add another just for it.
What is necessary, though, is to “pseudocode” my next steps. The basic layout and component structure is essentially complete, so it’s time to map out the functions required for the game. I’ve written down a few, but I’ll hold off on sharing them for now.
Instead, I’d like to share a little bit about Bitcoin and the MoneyButton API. For those that know me, I’ve been borderline-obsessed with Bitcoin ever since I discovered it. What may be a bit hazy to those people — is why. The reason why I have such a passion for Bitcoin, is because it has the potential to become the best form of money to ever exist (among other things).
With Bitcoin, we have cheap-to-send, programmable money that can be *surprise surprise* programmed into applications, websites, and more. If I completed this Yahtzee app and launched it into the wild for people to play, I could charge $.01 in order to play it. And the best part about this is, I don’t need to know squat when it comes to “coding in Bitcoin.” All I need to do is plug in the MoneyButton API, add some Javascript-based code into the application, and Viola! I’m connected to the Bitcoin blockchain, and payments can be automatically routed to my wallet each and every time someone decides to shake some dice and play my game.
Pretty cool, huh? I sure think so. And I also think the “Bitcoin piece” for this blog should remain short and sweet, so I’m going to listen to that little voice in my head and stop writing about it now.
So, it’s onwards to the logic part of this Yahtzee equation. Unfortunately, that little voice in my head had another message for me. This time, it told me I’m going to feel like I’m on the other end of the bipolar spectrum. Feeling like a wise wizard was only temporary; feeling like a total dunce is going to be my new reality. Argggv…
Hope you enjoyed the “Softening the Hardcode” edition of “A Coding Blog Bitcoin Story.”
Until next time, fellow coding or Bitcoin enthusiasts.
