DEV Community: Daniel Joo

A quick explanation/example of closure in JS

Daniel Joo — Sat, 11 Apr 2020 19:15:39 +0000

Hope everyone is staying safe and healthy during these crazy times! Just wanted to briefly explain the main concepts of closure, along with providing an example that highlights these concepts. So let's dive right in.

What is closure?

Simply put, closure occurs when a function accesses a variable that is outside its scope. This function is also invoked in a different scope from that of the variable. We can say that a function 'closes' over that variable. In easier terms, a function has access to a variable that is outside the function. Closure can only happen through an invoked function that references a variable(s) that is outside the function and outside the function's scope.

Enough words and abstract ideas, let's see this in a concrete example:

var day = "Friday";

var hello = function dayOfTheWeek() {
    // we are closing over `day`,
    console.log(
        `Today is ${ day }.`
    );
}

day = "Saturday";

hello();
// Today is Saturday.

In this example, the function dayOfTheWeek is called and closes over the variable day. day is declared and is assigned the value 'Friday,' but is later reassigned the value of 'Saturday'. This concept might seem very similar to scope, but the key difference is this: closure applies specifically to functions. Each time a function like dayOfTheWeek is called, there is a new closure. In Javascript, closure ensures that outside variables, which may be in an outer, enclosing function, are not garbage-collected (or GC'ed) once that outer function is done running. Closure allows the inner-scope function to have live access to those variables.

Here is another example, which might be very confusing at first.

var keeps = [];

for (var i = 0; i < 3; i++) {
    keeps[i] = function keepI(){
        // closure over `i`
        return i;
    };
}

keeps[0]();   // 3 
keeps[1]();   // 3
keeps[2]();   // 3

You might expect the function calls at the end to produce the outputs 0,1, and 2. However, 3 is returned for all three. Why? It's because of closure. The function keepI is called inside the for loop, and closes over the global var i during each instance of the loop. Although each function instance has its own closure, it closes over the same variable i, which takes on the value of 3 at the end of the loop.

Function-level Scoping in pre-ES6

Daniel Joo — Sat, 04 Apr 2020 22:07:07 +0000

Before the introduction of const and let in ES6,var reigned supreme and was used for all declarations/identifiers. The use of var is still quite common today, either through legacy code or in new code. Although there is a lot of debate over where and when var declarations should be used, I want to show some of the pre-ES6 function scoping.

function difference(x,y) {
    if (x > y) {
        var z = x;    
        x = y;
        y = z;
    }

    return y - x;
}

In this example here, we have a function where we want the difference between the two numbers to be positive. If x is greater than y, then we assign the value of x to z, which is declared in this function scope. Then, we take steps to essentially switch the values of x and y. In the end, we return y-x, which should be a positive number.

I want to bring attention to z declaration in this function. var identifiers within functions are accessible across the whole function. They attach themselves to the nearest enclosing function, no matter where they may be within that function. So in this case, although z may have been declared in the if block, it still belongs to the function scope. Unlike let or const, var declarations cannot create their own block scope. So although z has been declared inside a block, it does not create a block scope. Also, to be completely clear, not all blocks create their own scopes as well.

Theoretically then, for the function above, we could change it so that it looks like this:

function difference(x,y) {
    var z;

    if (x > y) {
        z = x;    
        x = y;
        y = z;
    }

    return y - x;
}

This version of the function would exhibit the exact same behavior since z belongs to the function scope. One possible argument I could have against this version, however, is that putting z outside the if block would signal that it's available and ready to be used within the whole function. While this is true, it's only technically needed for the set of statements within the if block. So putting the declaration of z inside the if block would semantically show that z is only needed for the part of the function inside the if block, although functionally, nothing changes. In other words, it semantically shows that z is block scoped.

In ES6+, we could incorporate let and simply swap out var for let.

function difference(x,y) {
    if (x > y) {
        let z = x;    
        x = y;
        y = z;
    }

    return y - x;
}

In this ES6+ version, this let declaration also creates its own block scope within the if statement.

Difference between == and === in JS

Daniel Joo — Sun, 22 Mar 2020 04:36:58 +0000

Anyone new to Javascript can at one point find themselves asking this very question when dealing with these comparison operators. This short answer is this: == requires that the variables on either side are of the same value, while === requires both variables to be of the same value AND the same variable type.

For ==, type coercion is performed. Type coercion is when the variable types for both variables are set to the same type before the values are compared. Here is an example of all this:

const variable = '3'
const variable2 = 3

console.log(variable == variable2)
// true
console.log(variable === variable2) 
// false

In this code, the first console log statement returns true. This is because type coercion makes both variables to have the same type. The second console log statement returns false because although both variables have the same value, variable is a string, while variable2 is a number.

Understanding the Key Concepts of Compilation in JavaScript

Daniel Joo — Sun, 15 Mar 2020 05:17:32 +0000

JavaScript can be best described as a compiled language. One may ask, "What is a compiled language?" Simply put, compilation is when code is transformed, through a series of steps, into instructions that your computer can then execute. During compilation, the entirety of the code is changed all at once. JS programs are run through two phases: compilation and execution. The programs are compiled before they are executed.

Compilation is important to consider and learn because it is during compilation that scope is determined. The scope, in turn, affects how the program is executed. Compilation broadly consists of three stages: Tokenizing/lexing, parsing, and code generation.

First, tokenizing/lexing is when the code is split up into meaningful chunks. For example, var c = 0 can be split up into the tokens var, c, =, 0.

Parsing is when these tokens are collected and formed into the Abstract Syntax Tree (AST). The AST can be describes as the grammatical structure of the program. According to Wikipedia, it is "a tree representation of the abstract syntactic structure of source code written in a programming language." To simply put, it represents the structure of the code. Lastly, during code generation, the AST is transformed into executable code.

So what exactly is the significance of compilation on how code is executed? Is there actual proof of compilation? Consider the code below.

var month = "It is March, 2020.";

console.log(month);

var month = ."It is March 14, 2020.";
// SyntaxError: unexpected token .

When this program is run, the console.log statement is in fact, not executed. This is because of the syntax error, which comes from the period, in the redeclaration of var month. This shows how the code is first compiled and then executed. Otherwise, the console.log statement would have been executed and then the error would have appeared.

Class vs Pure vs Functional Components in React

Daniel Joo — Fri, 03 Jan 2020 16:30:15 +0000

When first learning React and looking through source code on the Internet, I found myself slightly confused by the different types of components. Although one could go about only using class components throughout his or her application, pure and functional components can come in handy and allow for more clarity/organization within an application. Let's get into the differences between the three components.

Class components

Class components are the go-to components in React. They can be used exclusively throughout an entire application, and are the components that are most frequently used. Here is an example of a very simple class component.

   import React from 'react'

   class App extends React.Component {
     render() {
      return <div></div>
      }
   }

   export default App

Pure components

So what exactly are pure components? As the name suggests, the concept of a pure component is very similar to that of a pure function. In a pure function, if you put in the same input "x" number of times, you will get the same output "x" number of times. Putting in the same input will always lead to the same output in a pure function. Similarily, if a pure component is given the same state and props, it will always behave in the same way. A pure component does not have access to shouldComponentUpdate. What this means is that there is an automatic, shallow comparison of old and new props and state. Pure components are written pretty much the same way as class components with a minor tweak.

   import React, { PureComponent } from 'react'

   class App extends PureComponent {
     render() {
       return <div></div>
     }
   }

   export default App

Functional components

Functional components come in handy when you know that you don't need to include state or lifecycle methods in your component. Class components automatically check for lifecycle methods, and if you don't need to utilize them, you can simply use functional components. Because there are no lifecycle methods, render is not used. Functional components are a good option when all you want do is display something in your component and not include logic. They can take in props from parent components and re-render based on changes in props in the parent components. Functional components can also re-render if their parent components re-render. A functional component returns JSX and can be written like this:

   import React from 'react'

   const App = props => {
     return (
       <div>{props.message}</div>
     )
   }

   export default App

Using a Switch Component in React Router

Daniel Joo — Tue, 10 Dec 2019 19:15:34 +0000

Routing in React can be a little difficult for those who are new to React. It is pretty different from the routing system used in Ruby on Rails because it is now done completely on the client. The client is responsible for all routing in React.

When working with routing in React, I came upon the <Switch /> component and noticed how people were using that in place of <Router />. This made me delve a little further into the differences between the two and why using <Switch /> can be very helpful and the preferred component between the two.

<Router /> can include many nested routes that render inclusively. And what does "render inclusively" mean? It just means that whenever a route's path matches the url path, the router will render the route's component. Let's take a look at the below example.

   ReactDOM.render((
       <Router>
         <Route path="/" component={Home} />
         <Route path="/login" component={Login} />
         <Route path="/explore" component={Explore} />
       </Router>),
       document.getElementById('root')
   );

In this example, when a user goes the url path /, the Home,Login, and Explore components will all render. This is because all three routes include / in their paths. The <Route /> component is handy in this way in that it can render certain components all the time, such as the header, nav bar, and other components that should appear on every page of a website.

One way to ensure that routes don't render inclusively is by adding "exact paths" to routes.

   ReactDOM.render((
       <Router>
         <Route path="/" component={Home} />
         <Route exact path="/login" component={Login} />
         <Route path="/explore" component={Explore} />
       </Router>),
       document.getElementById('root')
   );

Above, I added an exact path to the login route. So when we visit /login, only the Login component will now render on the page.

So what exactly is the advantage of using <Switch />? The <Switch /> component will only render the first route that matches/includes the path. Once it finds the first route that matches the path, it will not look for any other matches. Not only that, it allows for nested routes to work properly, which is something that <Router /> will not be able to handle.

   ReactDOM.render((
       <Switch>
         <Route exact path="/" component={Home} />
         <Route path="/login" component={Login} />
         <Route path="/explore" component={Explore} />
       </Switch>),
       document.getElementById('root')
   );

In the example above, when the user goes to /login, only the Login component will now be rendered. It is also important to note that an exact path can and should still be utilized for routes that are inside a <Switch />. An exact path for a route that is inside a <Switch /> makes sure that the route matches exactly the path that is specified. For example, without the exact path for / above, a user who goes to /login would find the Home component rendered on the web page.

The differences between typeof and instanceof in OO JS

Daniel Joo — Fri, 15 Nov 2019 18:10:04 +0000

I want to explain the differences between the typeof and instanceof operators in object-oriented JavaScript. Both of these operators can be used to find out more information about a certain piece of data.

typeof is an operator that can be used to verify what datatype a certain "operand" is. An "operand," as mentioned in the MDN documentation, is just a piece of data that is being manipulated or worked on. This operand can be pretty much anything, from a variable that contains a value to a function. When using typeof on an operand, all you need to is simply state typeof right before the operand.

Here are two examples:

const a = 6;
typeof a;
//"number"


function hello(name) {
  return `hello, ${name}`
}

typeof hello
//"function"
typeof hello()
//"string"

In the first example, we are using typeof on the variable a, which contains the value of integer 6. Therefore, the return value is "number," because 6 is a number/integer.

The second example is a little more tricky. Here, we have the hello function. When using typeof on hello, we get the return value of function. This is because hello refers to the function body, or the code that is between the brackets, also known as the code block. If we call typeof on hello(), however, we get the value of string. This is because the function is now being invoked, and therefore returns the string within the code block.

The instanceof operator tests to see whether the operand is an instance, or object, of a certain class. In JavaScript, just like initialize method in Ruby, instances of a class can be created/initialized with certain attributes using the constructor method. This makes each instance of a class unique. Let's take a look at this example:

class Person {
   constructor(name,age) {
   this.name = name
   this.age = age
   } 
}

const person = new Person('David',22)
const david = new Person

console.log(person.name) 
//"David"

console.log(person.age)
//22

In this Person class, each new instance of Person will be created with a name and an age. this refers to the object/instance that is currently being created and initialized. this is similar in concept to self in Ruby.

With this knowledge of the constructor method in JavaScript, we can use the instanceof operator to verify whether the operand is actually an instance of a certain class. typeof returns a boolean value. Using the Person class above, we can use instanceof to verify whether person is an instance of the Person class.

console.log(person instanceof Person;)
//true

console.log(david instanceof Person;)
//true

When applying this to person and david, we can see that both of the expressions return the value of "true." This is because both are instances of the Person class.

To summarize, typeof and instanceof are neat little operators that can be utilized when trying to verify the properties/characteristics of objects and data in JavaScript.

Strong Params with Custom Arguments

Daniel Joo — Fri, 25 Oct 2019 15:37:21 +0000

Strong Params are used in Rails to make sure that users can only pass in values for permitted parameters when sending POST requests to the server. For example, when updating a blog post, a user will only be able to update the attribute parameters for the post that have been permitted by the developers for users to edit/update.

Custom arguments for strong parameters are a helpful way to ensure that the user cannot update the values for certain parameters after the object has already been created (through a form_for).

In the example shown here, I have a private strong params method. It's called task_params and takes in custom arguments for what params are permitted for a user to enter values for when creating and updating a task. The method requires that there be a task, and what is being permitted is up to the developer's digression later on in the Tasks#create and Tasks#update methods.

In the Tasks#create controller action, there are 5 parameters that are being permitted. There is the assigner_id, title, category, priority, and content. These are the only attributes of a task object that the user can pass in values for when that user creates a task on a form.

However, because the task_params method has custom arguments, now I can permit different parameters when users want to update a preexisting task. Let's say that once a task has been assigned to someone(the assignee), the assignee for a task cannot be changed. In the Tasks#update action, you can see that the assignee_id parameter has now been taken out. As long as take out the form field for assignee_id in the corresponding form on the edit view page, users will now only be permitted to update values for the remaining 4 parameters.

Passing custom arguments for strong parameters is definitely a neat and simple way to control what users can and cannot update!

The Convenience of Faker

Daniel Joo — Thu, 03 Oct 2019 20:10:01 +0000

When working on a new project, everyone needs to populate their databases with some data. This can be a daunting task, especially for beginners to programming. In Ruby however, there is a "Faker" gem, which, upon installing, can make that task a whole lot easier. There is pretty much no need to hardcode any fake data when you need a lot of data!

What Faker does is generates fake data for your database. Before you use Faker, three things need to be done. First, you have to install the gem with "gem install faker." Second, you must set up made a migration for your tables and have your schema ready. This can be done through Active Record. Lastly, you need to require Faker on your gemfile. Now, you are all set to use Faker to generate this fake data!

Faker is such a convenient tool, and although I won't get into the specifics of how to actually incorporate it into the code, everyone who works with Ruby on their personal projects should utilize it.