Beginner’s JS – Week 2

The big focus of this week was on learning the basics of Functions as well how to to go about finding why a function might not be working via various debugging methods.

Setting Defaults on Arguments

My biggest takeaway from the Functions lessons was the ability to set default values for a function’s arguments, which is something I had run into previously. To illustrate this, let’s imagine that you have a function which takes-in three arguments, then does some work, and spits back an answer. A simple example of this would be a function which finds the volume of a room, where we give the width, length, and height, then it would return us the cubic feet (or meters) of the space.

// Function Declaration
function volumeCalculator(width, length, height) {
    const volume = width * length * height;
    return volume;
}
// Gives us 1,600 cubic feet
console.log(`The volume is ${volumeCalculator(10, 20, 8)}`);

This is great, but sometimes we only have 2 of the 3 values and we might need to skip the Length, which presents an interesting problem. So if we have our Width and Height, but we want to skip the Length and just assume a default value, we can declare it directly in the function’s parameters like this:

function volumeCalculator(width, length='20', height) {}

Now, if we go to call the volumeCalculator, we can skip-over theLength property and the function will assume a default value of “20” for us instead. In order to skip a value when calling a function, we need to pass-in “undefined” as the value. So all together, this would look like:

volumeCalculator(10, undefined, 8);

Since the “undefined” isn’t a value, the function falls back to a preset default in order to prevent an error from occurring, which is super handy when making functions which might have a default, or extremely common set of values.

Debugging

Most of the topics covered within the debugging section I’ve used previously, but I did learn about a fun feature of Chrome’s Developer Tools which will come in handy. It turns out that within Chrome Dev Tools you can actually just right-click then add a “break on” right from the Elements tab, then whenever the item changes it’ll pause the browser and zoom you to where the javascript that made the adjustment is being called, which is super nice. This comes in handy when you’re not sure what might be the source of an element’s changes– such as if you’re working on someone’s else’s codebase and you need to find which code is controlling the homepage slider. You could just “break on” the homepage slider, and see when the element goes to update where the code is being run.

Scoping

Much like debugging, most of the Scoping topics I was familair with, however there was some fancy work-arounds for some simpler issues if I ever happen to run into scoping problems in the future. Most notably is how it’s possible to bypass scoping if you ensure that the variable is declared outside of a function before it’s assigned a value. Basically, if you are creating a variable inside of a function and you need access to the variable outside of the function, you can define the variable outside of the function, update its contents within the function, and then the variable will have the updated content available globally. To illustrate this I’ll write two different code blocks, one which defines the variable inside of a function, and one which defines it prior to the function running:

// Does not work:
if (1 === 1) {
    let cool;
    cool = true;
}
console.log(cool); // Result: Cool is not defined


// Does work
let cool;
if (1 === 1) {
    cool = true;
}
console.log(cool); // Result: Cool is `true`

Closures

Closures and nested-scope are very interesting topics to say the least. Scoping makes sense for the most part, with some high likelihood I’ll find myself debugging scoping issues in the future when I find that a variable or a function isn’t accessible to me when I assumed it would be available, however when it comes to Closures it’s like a whole different ballgame. Closures feels like a combination of “you could probably refactor your code to be more explicit to avoid the issues caused by Closures”, but at the same time it also feels like “you’ve pulled back the curtain of the heavens and now God will spite you”.

Closure is essentially what happens when you try and access information which was scoped to the inside of a function, but the function has already run and “closed”, meaning that the interior information which was calculated has been deleted, removed, or tossed in the garbage. Closure allows you to reach back into functions which were already run and pull out that information an additional time if needed. From what I’ve seen so far this appears to pop up in nested functions, where you need access to the 1st-level function’s information when running the 2nd-level function at a later time, something which normally wouldn’t be possible.

Overall I’m still extremely confused by closures, but I think that given more time and context it will make more sense in real-life scenarios.