JavaScript for Beginning Beginners and Creating Your First JS App with Rails API. () => {
(key info to share during my torrid affair with learning javascript. twice.)
Most people won’t come into Javascript with a prior knowledge of Ruby on Rails. I did, and that made some of the transitions helpful, especially with making analogies along the way. But even for someone where some of the code was familiar, I still had a huge struggle to wrap my head around the beginnings of JavaScript. So, I’ve tried to parse out a few nuggets of information.
let theseWords = a minor attempt to Console those that have some initial struggles.
HTML has <div>, Ruby has end, and JavaScript has the fancy brackets. Or “braces”.
In JavaScript (not Java!), you’re going to have a good number of functions. And a good number of those functions are going to be nested functions. Callback functions alone can be complicated enough with the amount of instructions you’d like to your programming to run. It is very easy to get bogged down and lose time trying to figure out where your “expected }” error is coming from. And you know I’m right. If your VSC (or coding studio of your choice) has Prettier installed, you’re on the right track. But in the midst of making fixes, it’s very easy to lose a bracket, parenthesis, or both! A great tool I found is: Bracket Pair Colorizer 2. It doesn’t always find out what’s missing, but makes it easier to find my color coding your nested functions. I think it has saved me minutes per hour, which adds up fast over a big project.
CONSOLE. LOG. EVERYTHANG.
“Nothing consoles and comforts like certainty does.”
― Amit Kalantri, Wealth of Words
“Nothing comforts like console.log() does.”
— Ryan Bollettino, This Blog
“Console. Log. Everything.” — smart coders.
At the beginning(s) of this Javascript phase for my schooling, I heard that phrase many times over. It took me a few early labs to finally realize the importance of these choice words. It is very easy to go down a rabbit hole and lose your way as you start typing out your code solutions. But like that other story with a rabbit, slow and steady wins the race. And the best way to that along the way is to check your work every step of the way. Add an event listener? Make sure it’s listening!
Otherwise, you’ll write 12–15 lines of code and think you’re brilliant (and you are, truly, we all believe in you), but you are also human, and can easily make a mistake in JS. So while you may still make mistakes, at least you’ll know where they are coming from!
To Build in HTML or in JS? That is the Question.
Tis nobler…eh. Ahem. This is something I’ve gone back and forth on, and it seems like it’s personal preference, and depends on your comfort with creating inside of HTML vs your willingness to explore the nuances of JS.
The second option uses the (``) slanted quotes instead of the usual single or double-quotes used for naming id’s, classes, etc. in JS. The slanted quotes allow for template literals within the HTML you’re adding inside a container.
Granted, both formats use the forEach method. The top method has the forEach as part of the actual function. For the lower, an object from a forEach operation is passed into the above function. If your function needs to be self-contained, use the first. If it is part of a larger nested function, that will have the correct arguments passed to it, use the latter.
Rendering Nested Objects Within Your API:
I created an app that was a nice SNL Database app that allows you to add SNL Members, and then add their Characters to the database as well (coincidentally the week of Norm McDonald’s death — RIP). The way I had my layout structured, I wanted to be able to call on data from both the SNL Member and their Characters, and I didn’t want to have to pull from two separate Objects.
Cue: conditional rendering. I created a Member with the Character object attached through foreign keys, (member_id in this case), characters belong_to Members, Members has_many Characters….AND characters will be destroyed along with their Member if the Member is deleted. Wanna delete Chevy Chase from the database? Bye-Bye Land Shark and Gerald Ford! Easy to do by adding dependent: :destroy inside your parent model.
But, I digress. Here is some formatting that will make it a lot easier to grab all the necessary data you’d like to render with a little one stop shopping. Using the except:/include: commands, you’re able to use your Parent class as one large object that has the -in this case — characters already part of your Members.
The code above can be written quickly in only one place and allows you to control all the information that will flow from whichever model you’re accessing (and all those that belong_to it!)
When I needed to render my Characters, I fetched the Member whose id matched the actor. From there, I iterated through all of that Member’s characters, assigned each Character specific attributes by name, and sent each fully formed Character into the render function to display them.
The biggest challenge was learning how to adapt everything we’ve learned with Rails and JS in a short time, and apply it to new Classes that we had to create to contain the functionality for our parent and children classes. The last line above (line 106), took some time to recall how to call functions on an instance. Something I don’t recall doing since the Sinatra days of working deeply within Ruby classes. That seems like a lifetime ago, although it was a scant 6 months or so. Time flies when you’re looking for that missing bracket.
