DEV Community: Andrew Koenig-Bautista

JavaScript Hoisting: let & const

Andrew Koenig-Bautista — Sat, 04 Apr 2020 07:01:01 +0000

The term hoisting is confusing

I believe that one of the first and foremost reasons people struggle to understand hoisting is because the term itself is somewhat misleading. The Merriam-Webster definition of the word hoist is "an act of raising or lifting".

This might lead one to assume that hoisting involves written code being physically rearranged somehow. This is not true.

Instead, the term hoisting is used as a kind of simile to describe a process that occurs while the JavaScript engine interprets written JavaScript code.

How is JavaScript code interpreted?

All written JavaScript is interpreted within the Execution Context that it is written in. When you open up your text editor and create a new JavaScript file, you create what is called a Global Execution Context.

The JavaScript engine interprets the JavaScript written within this Global Execution Context in two separate phases; compilation and execution.

Compilation

During the compilation phase, JavaScript parses the written code on the lookout for all function or variable declarations. This includes:

-let
-const
-class
-var
-function

When compiling these keywords, JavaScript creates a unique space in memory for each declared variable it comes across. This process of "lifting" the variable and giving it a space in memory is called hoisting.

Typically, hoisting is described as the moving of variable and function declarations to the top of their (global or function) scope.
However, the variables do not move at all.

What actually happens is that during the compilation phase declared variables and functions are stored in memory before the rest of your code is read, thus the illusion of "moving" to the top of their scope.

Execution

After the first phase has finished and all the declared variables have been hoisted, the second phase begins; execution. The interpreter goes back up to the first line of code and works its way down again, this time assigning variables values and processing functions.

Are variables declared with let and const hoisted?

Yes, variables declared with let and const are hoisted. Where they differ from other declarations in the hoisting process is in their initialization.

During the compilation phase, JavaScript variables declared with var and function are hoisted and automatically initialized to undefined.

console.log(name); // undefined
var name = "Andrew";

In the above example, JavaScript first runs its compilation phase and looks for variable declarations. It comes across var name, hoists that variable and automatically assigns it a value of undefined.

Contrastingly, variables declared with let, const, and class are hoisted but remain uninitialized:

console.log(name); // Uncaught ReferenceError: name is not defined
let name = "Andrew";

These variable declarations only become initialized when they are evaluated during runtime. The time between these variables being declared and being evaluated is referred to as the temporal dead zone. If you try to access these variables within this dead zone, you will get the reference error above.

To walk through the second example, JavaScript runs its compilation phase and sees let name, hoists that variable, but does not initialize it. Next, in the execution phase, console.log() is invoked and passed the argument name.

Because the variable has not been initialized, it has not been assigned a value, and thus the reference error is returned stating that name is not defined.

Where can I reference let and const?

Again, variables declared with let and const are only initialized when their assignment (also known as lexical binding) is evaluated during runtime by the JavaScript engine.

It's not an error to reference let and const variables in code above their declaration as long as that code is not executed before their declaration.
For example, this code works fine:

However, this will result in a reference error:

This error is generated because greetings() was executed before the variable name was declared.

Building an Etch-A-Sketch with JS/CSS/HTML

Andrew Koenig-Bautista — Sun, 29 Mar 2020 17:59:58 +0000

I recently built an etch-a-sketch variant as an exercise for practicing basic JavaScript, CSS, and HTML. As usual, it was simultaneously easier and harder than I expected. I want to take the time to document my experience in order to strengthen my understanding of what I built and to avoid the "I don't know how it works, but it works!" perspective.

HTML

I started with a basic HTML skeleton:

Simple enough! I then filled in this HTML skeleton with the extra bones that I felt my project would need:

I wanted to have my "Etch-A-Sketch" grid take up the right half of my page with the title and interactive elements sitting on the left. To this end, I wrote a div with the class "right" to contain elements on the right half, which for my project is simply the "gridContainer" div.

I followed up with a div named "left" to contain the elements to be delegated to the left-hand side. Here I included my title as a header element, added an input for users to change the number of squares in the grid, and wrote in a reset button meant to clear the grid and make it revert to its default size.

I ended, of course, with a script tag for my JavaScript.

CSS

Next, I will break down my CSS file. Here's the final product:

Again, pretty straight forward for the most part.

I centered the text on the page and chose Monaco as my font. Monaco is a fun, retro-esque font that gives off a digital vibe.

I gave the squares that would eventually make up my grid a white background and black border and wrote a separate class with a gray background to be triggered when users hover over the grid with their mouse. I initially had given my squares some padding but removed it after realizing that this would change the overall grid size.

The CSS for my 'gridContainer' took some playing around with because I am not yet skilled with CSS-grid. In retrospect, it looks very straightforward, but it was a bit of a struggle while building it.

All I needed to do was set my display to inline-grid, and then set a default number of rows and columns for my grid using 'grid-template-columns' and grid-template-rows'. I gave my Etch-A-Sketch grid a set height and width and gave it a default of 16 rows and 16 columns.

If you want to learn more about CSS grid layout this is a great resource.

JavaScript

Of the three sections, this one is slightly more complex. Here's the code:

First I created variables to grab the grid, user input, and reset button divs.

The first function I wrote is 'createGrid()', a function that as the name suggests, builds out my Etch-A-Sketch grid. This function consists of a for loop that runs 256 times, creating 256 'square' divs that are appended to my grid. Because the CSS for my grid is set to a default of 16 rows and 16 columns, these 256 squares will perfectly fill it out.

The next function is 'updateGrid()' and it enables users to dynamically change the number of rows and columns that make up the Etch-A-Sketch.

First off I clear out the innerHTML from the default grid build so that we're not continuously stacking new squares on top of old ones. Next, I use JavaScript to change the grid CSS columns and rows by plugging in the user input. Lastly, I wrote a for loop that will implement the user input to build and append as many squares as needed to fill in the new number of columns and rows.

After defining these functions, I grab the div 'square' elements in a variable called square. I then added an event listener to every square that will listen for 'mouseover', and when the user passes over a square with their mouse, that square will be assigned a new class, which will change its background color from white to gray.

I also added an event listener to the input field so that the 'updateGrid()' function will trigger once a user has typed a new value for resizing the grid.

Finally, I added an event listener to my reset button. This JavaScript clears out all the existing grid HTML and resets the grid CSS to its default values. It then triggers 'createGrid' to rebuild the default.

And the final product looks like this:

3 Examples Of When Not To Use Javascript Arrow Functions

Andrew Koenig-Bautista — Sat, 21 Mar 2020 22:31:46 +0000

Photo by Nick Fewings on UnsplashES6

Arrow Functions

You know them, you love them, and you probably use them all the time! Introduced as part of the ECMAScript 6 update in 2015, arrow functions exploded in popularity, and with good reason. Arrow function syntax is wonderful syntactic sugar that removed the need for the following:

-the return keyword (for one line functions)
-the function keyword
-curly brackets

Arrow functions also reduced some of the complexity involved in JavaScript function scope as well as the this keyword, because sometimes all you really need is an anonymous function.

All that being said, arrow functions are not a one size fits all solution for every need you will encounter when writing JavaScript functions. Let's dive into a few situations in which arrow functions are not the right answer.

Object Methods

Let's say you want to create a method to bind to an object.

In this example, if we call mario.oneUp() we expect the value of mario.lives to increase from 3 to 4. However, as currently written the value of lives will remain unchanged regardless of how many times oneUp() is invoked.

Why is this? The answer is this !

With arrow function syntax, this is inherited from the parent scope, which in this case would be window because an arrow function is always bound lexically with the window object.

So in this case, invoking oneUp() would be asking your program to increment lives in the window object, which of course does not work.

Object Prototype

Here's the JavaScript snippet we will be working with for this example:

Our function invocation on line 15 would out the following:

true
undefined

We defined the speak() prototype function and passed in a catchphrase for our new Robot object, so why does this code evaluate to undefined?

The console.log() reveals why. As you can see, when we ask the console to evaluate if (this === window), it returns true. This provides proof of what we discussed in the previous Object Methods example.

When working with functions that require context, we must use the regular function syntax in order for this to be properly bound:

Dynamic Context

Here's our final example:

By now you're probably aware that this code will not work, as well as why it won't work. I'll give you a hint, it has something to do with this, again.

Arrow function syntax binds context statically upon function declaration, which is the opposite of what we're trying to achieve when working with event handlers or event listeners, which are inherently dynamic.

When manipulating the DOM via event handlers or listeners, triggered events point to the this belonging to the targeted element.

For an arrow function defined in the global execution context, this will point to window. So in the above code, this.classList will evaluate to window.classList, resulting in a TypeError.

That's all folks!

I hope these examples were easy to follow and understand. If not, I would recommend reading up on this in JavaScript to help augment your understanding of when to use or not use arrow functions.

As always, thanks for reading!

Artful Design for Aspiring Developers

Andrew Koenig-Bautista — Sat, 07 Mar 2020 22:53:09 +0000

As a programmer in the midst of honing my skills, when I write code my first priority is writing code that works. I ask myself questions along these lines: does this code provide the user experience that I’ve been asked to deliver? Are there areas where user interaction could break this code? Does my program get the user from point A to point B? To sum it all up; is this code functional?

At this stage in my career, it is normal to have this mindset. My focus is function over form. However, as I progress and my abilities continue to grow, my goal is to shift to a mindset that melds form and function. The melding of these two areas of focus is something that Stanford professor Ge Wang calls “Artful Design”.

In his book of the same title, Wang lays out principles of Artful Design and breaks down how and why they matter when creating products centered around user experience. I’m going to cover a few of his principles that stood out to me and how they have shaped my approach to programming.

1. Invite the Senses

Let’s say you stumble on the fountain of youth this weekend. Eternal life, forever young, the whole kit and caboodle. Apart from the obvious health benefits, you’ve basically won the lottery. It’s time to bottle up this magic and sell it to the masses at a premium. However, in your rush to be the next Jeff Bezos, you hire the cheapest designer you can find. You think to yourself, designing a water bottle can’t be that hard, right? You okay the design without even looking at it and give the all-clear for mass production. And when you walk into 7–11 to see your baby on the shelf, you see this:

You can kiss your billionaire status goodbye, ladies and gents. This product does not invite the senses. If it doesn’t catch the eye, it’s certainly not going to catch any dollars (or clicks, in our case). Even the greatest products can fail as a result of poor aesthetic design. In applying artful design to front end web development, here are some questions to consider:

Visually, is my site interesting, or pleasing to look at?

We’ve all seen ugly websites. Most of us have had the displeasure of trying to navigate ugly websites as well (if you’ve ever tried to defer jury duty over the internet, you know what I mean). Landing pages especially should create a sense of calm. Users should think to themselves “This makes sense. I know what this site is for. Looking at this site does not make me want to scream”.

Does your site invoke a desire to explore?

It can be tempting to lean toward providing the user with many, many, many options, buttons, links, etc. but too many options usually result in an exhausting user experience. For example:

https://www.uat.edu/

As programmers, we can and should create intrigue without overwhelming. Users should think “I wonder what else I can do? The presentation of this site inspires curiosity, I want to know more!”

2. Pragmatics: “It’s Gotta Read!”

Does my code lead to an intuitive user experience? Most users are not programmers. Most people do not look at a site and think “Wow, this is some slick HTML, very impressive”. Our programs should be as simple, straightforward and easy to understand as possible. This requires us as programmers to know our audience. What background experience and expectations does that audience bring to the table? (for example, the term “football” can mean two different sports depending on your audience)

“It’s kinda like telling a joke -you don’t get to explain it afterward!”

To some degree, a site designed to be intuitive is a site that is predictable. Predictable, in this instance, does not mean boring. A predictable site is one in which users have the comfort to think “Hm, just from looking at this page, if I click/type/scroll here, I think x will probably happen”

nike.com

3. Useful and Beautiful

Value the user. At times, and especially under a time crunch, it can be easy to forget that we are not coding programs to meet deliverables and be used by robots, the programs we code will be used by humans, and “design is the art of humanizing technology”. This is where we confront the gap between design that is a means to an end vs. design that is an end in itself.

For example, some people may play sports or create art or write code as a means to an end (make the NFL, achieve fame, become rich) and there’s nothing wrong with that, but for some, these activities are ends in themselves. When we code in a way that values the user, we can strive to create products that are a means to an end and ends in themselves.

“Design is the radical synthesis of means and ends into a third type of thing -both useful and beautiful”

Form and Function

As human beings, it is almost impossible to separate our functional use of a product from our experience of the form of that product. Human beings value superfluous, unnecessary, and even useless things. We don’t need color, style, or comfort, and yet we want and even expect these concepts to be a part of the products we use and the experiences we pay for. They appeal to our inherent playfulness, delight, and curiosity. With the right mindset, our code can do the same. We can move on from the battle of function vs. form to the more human combination of form and function.

*principles and quotes credited to Ge Wang and his book “Artful Design”

What Is the Best Way to Convert a String to a Number in JavaScript?

Andrew Koenig-Bautista — Mon, 10 Feb 2020 00:08:17 +0000

(photo by Volkan Olmez on Unsplash)

Read on Medium:

The Best Way to Convert a String to a Number in JavaScript | by Andrew Koenig-Bautista | Better Programming | Medium

Andrew Koenig-Bautista ・ Mar 6, 2020 ・ 4 min read
Medium

As you probably already know, there are a variety of ways to convert a string to an integer in JavaScript. However, it's up for debate as to which method is the "best" method available to developers. Let's take a look at some options.

parseInt()

parseInt(string, radix)

We begin with parseInt() which takes two arguments, a string and a radix. The function returns an integer parsed from the given string.

If the first argument is not a string, it is converted to one automatically using ToString(). Either way, any leading whitespace is ignored.

The parseInt() method starts at position 0 and determines if the character found there can be converted into a valid number. If not, the method returns NaN and stops. Here is an example:

const str = "What's funnier than 24?",
console.log(parseInt(str)) // NaN

The output would be NaN, in spite of the string containing a number.
If the character at position 0 is valid, the method moves on and carries out the same test. This goes on until parseInt() encounters an invalid number, at which point it will convert the current string into a number.

console.log(parseInt("24haha25")) // 24

This would return 24 as it would stop parsing at haha, which is NaN.
MDN suggests that when using parseInt() you should "Always specify a radix to avoid.. unreliable behavior." This is because pre-ECMAScript 5, parseInt() used the octal radix (8) as default if a string began with "0". As of ECMAScript 5, the default is the decimal radix (10):

If radix is undefined or 0, it is assumed to be 10 except when the number begins with the character pairs 0x or 0X, in which case a radix of 16 is assumed.

parseFloat()

parseFloat(string)

parseFloat() is quite similar to parseInt(), with two main differences.

First, unlike parseInt(), parseFloat() does not take a radix as an argument. This means that string must represent a floating-point number in decimal form (radix 10), not octal (radix 8) or hexadecimal (radix 6).

Second, when using parseFloat() a decimal point is a valid character, but only the first time it is encountered. If a second decimal point is reached, the method will stop parsing at that position.

console.log(parseFloat("3.141.59")) // 3.141

Otherwise, the other behaviors of parseInt() are found here as well:

-Only the first number in the string is returned
-Leading and trailing whitespace is allowed and ignored
-If the first character is not a valid number, NaN is returned

Number()

Number(value)

The parse functions and Number() are largely interchangeable. Number() can handle one decimal, but will also be thrown off by more than one decimal point. Leading and trailing whitespace are still accepted and ignored.

There are a few differences. The parse methods, as the name suggests, attempt to parse through a string piece by piece as they convert it, Number() attempts to convert the entire string argument into a number, all at once.

const str = '123abc';
Number(str); // NaN (attempts to convert entire string, cannot)
parseInt(s); // 123 (stops as soon as it hits `a`)

Number() is the JavaScript Number constructor called as a function, which performs a type conversion. It attempts to convert any value to a number:

-false becomes 0, true becomes 1
-null becomes 0, undefined becomes NaN
-Empty string '' becomes 0, non-numerical strings become NaN
-Number('') gives 0; parseInt('') gives NaN

Here's a Number() overview from w3schools:

Unary + Operator

You may or may not be aware of the ability of the + unary operator to convert a string to a number in JavaScript. For example:

+"123" // 123
+"123.456" // 123.456
+"123.456.789" // NaN
+"I'm a number" // NaN

As far as I know, using the unary + operator this way exactly mimics the behavior of Number() without any exceptions. So why use Number() at all?

Some people see the + operator as a form of syntactic sugar because it can be used to abbreviate the parse functions or Number() functionality.

However, less code does not always equal more concise code. Clarity should be taken into consideration when making decisions about shortcuts like this.

Not everyone may be aware of this behavior, which could lead to confusion for someone reading your code, whereas parseInt() is clear and concise.

In my opinion, generally speaking, you should use code that describes what it does instead of code that uses a side effect of a non-operation

Multiply by 1

Another shortcut of sorts, if you know the string that you are seeking to convert is a number, you can multiply it by one to convert it:

"123"*1 // 123
"123.456"*1 // 123.456
"123.456.789"*1 // NaN
"I'm a number"*1 // NaN

Again, this method behaves the same as Number() and I've seen it touted as being the fastest conversion method. However, my previous concerns about the usefulness of such syntactic sugar apply here as well.

So What Method Is Best?

I ask this genuinely, dear readers! Now that we've covered some (but not all) options here, I would love to hear your opinions on what method (or methods) you believe to be best (and why).

I'm sure many of you are much more knowledgable than I am about performance times, although the performance for operators and functions changes with the optimization of the JavaScript engine in browsers.

I hope to read some helpful and healthy debates, and if nothing else I hope this serves a good review and maybe you even learned something new.

Thanks for reading!

My First Crack at OOP in Ruby

Andrew Koenig-Bautista — Sun, 26 Jan 2020 00:28:52 +0000

Object Oriented Programming (or OOP for short) is a type of computer programming centered around -you guessed it- Objects. But what is an Object? And what does it mean for a programming language to be centered around the concept of Objects?

Let's start by digging in to that first question: what is an Object?
Unless you are a monk or a nun who is living in solitude and breaking your vows to access this blog (I'm honored) you're likely familiar with the team of superheroes known as "The Avengers". One of the most recognizable members of this super-team is the hero known as "Captain America". For the sake of this explanation, Captain America is going to stand in as our Object.

As if he hasn't been objectified enough over the last 80 years (sorry Cap).

In programming, an Object is an instance of a Class. Don't panic, we don't need to dive too deep into Class or instance right now. All you need to know is that a Class is a blueprint for creating instances of Objects. For example, we could say that our Object, Captain America, is an instance of the Class "Superhero". He is a Superhero Object. Other such instances of the class "Superhero" could be Spider-man, Wonder Woman, or Batman. At some dark, Avenger-less point in time, there was no such Object as Captain America, but then Joe Simon and Jack Kirby dreamed up a new instance of the Class "Superhero", and our beloved Captain Object was sketched into existence.

An Object has two defining features: attributes and behaviors. All human-like "Superhero" instances universally share a few basic human attributes. What are some of Captain America's? Let's see; hair: blonde, eyes: blue, shield: star-spangled. We can assign these descriptive traits to the Captain. But even the coolest attributes are not enough to fight crime on their own. Blonde hair doesn't punch, a boomerang shield isn't going to throw itself! To make use of these attributes our Object needs some behaviors.

Without behaviors (which manifest in code as methods or functions) our hero Object would just be a lifeless robot. He needs to be able to walk, run, jump, and kick! Maybe even shout a catchphrase?

Defining methods and functions for our Objects gives them the framework they need to interact with the world (or program, in our case) around them. A superhero can't just jump straight to fighting crime without first going through a training montage!

And with that step complete, we have now created a very (very) basic instance of an Object (in Ruby, which is an Object Oriented Programming language). The beauty of Objects is that they are self contained and independent of other Objects. They store a lot of data under the hood (Captain America has almost a century of knowledge stored under that helmet of his) and they provide a framework that can be reused or repurposed (maybe we could use Cap's "Superhero" class to make some more Avengers?).

And last but not least, they make debugging easier. Let's say we used this Superhero class to build out an Avengers (software) program, but one of our creations (maybe the Hulk?) doesn't quite fit in with the rest of the team and starts causing trouble aka bugs. To get our program back up to full crime fighting capacity, we could simply replace that Object with another hero Object that's a better fit (She-Hulk, perhaps?) without having to tear down the whole team (program) and rebuild it from scratch.

I hope this example is easy to understand and helps demystify OOP just a little bit for you. Until next time, true believer, keep programming and fight for "Truth, Tolerance, and Justice" - Clark Kent.