Overview: I love going to the beach! There’s so much to see and do, from the beach itself to restaurants, lighthouses, shops, and a whole host of other stuff. One of my favorite activities is to keep a journal of my beach trips; that’s always fun to read later, and it gives me a good idea of what to do and where to go the next time I visit. For my React/Redux project, I decided to make an online version of a beach journal, so I can use it wherever and whenever I want. It also makes it a lot easier to put all of the information about different beaches in one place.
In my previous blog post, I discussed how scope works in JavaScript. I explored a couple of key scope-related concepts, and I briefly touched upon closures. Here, I will conclude my discussion of scope by describing a couple of “exceptions” to the concepts that I previously wrote about. Then, I will describe hoisting and how it is closely connected with the JavaScript engine’s compilation and execution phases. An understanding of how scope, hoisting, and the JavaScript engine work, is critical to becoming a good JavaScript developer; a lot of bugs can be avoided or corrected, especially when dealing with legacy code.
Scope and hoisting are essential concepts to understand when programming in JavaScript. Scope is where a given set of functions and variables can be accessed. Hoisting is what allows for functions and certain variables to be accessed and manipulated from the top of the current scope, even when they are defined/declared further down in that scope. In order to fully understand hoisting, one must also understand how JavaScript’s engine works (i.e. what it does during the compilation phase and the execution phase, and the order that it runs through these phases). By knowing how all of this works together, one can avoid (or at least fix) a few commonly-encountered bugs in JavaScript code.
While I was working on my Crazy Coffee Concoctions project (see previous post), I ran into an interesting bug related to event listeners. Here was part of my project plan: When the index.html page was initially loaded, it would render a “New Concoction” form by default. When the user submitted the form, it would create a coffee concoction and display it. The user could also click on a “New Concoction” button to generate a new form for creating a concoction. In order for this to work, I attached a listener for the “submit” event onto the “New Concoction” <form> element. There was just one problem: The event listener worked on the <form> that was rendered by default, but not on the <form> that was rendered by the “New Concoction” button! In order to solve this bug, I had to learn more about how event listeners work. Later on, I learned that I could make my code even better with event delegation.
For my Rails with JavaScript project, I decided to make a more specialized version of my Sinatra project. For my Sinatra project, I had built an app called Recipe Rolodex, which allowed users to create, read, update, and delete their own recipes, and view the recipes that other users had created. My Rails with JavaScript project focuses specifically on coffee, so I am calling it Crazy Coffee Concoctions. Making this app has been quite the process!