Forem: Kelvin

Deep dive JavaScript: Scope

Kelvin — Wed, 22 Sep 2021 12:35:05 +0000

Are you always wondering how JS can understand our code, how scopes can be created?

You'll need to have a better mental model about how JavaScript engine handles our code in general. In this article, we are going through how JS scopes are created under the hood, step by step like:

Compilation
Parsing/Compilation phase
Evidences of code compilation
Briefly about lexical scope

What is Compiled and Interpreted?

Compilation is a process that turns your code into a list of instructions that your machine can understand

Interpretation is similar to compilation but instead of processing the whole source code, it will be processed line by line. Each line is executed before proceeding to process the next line.

Note: new JS engines actually use both compilation and interpretation to handle JS programs.

Step by step through compilation phase

JavaScript code is processed in 2 phases: Parsing/Compilation and Execution

Parsing/Compilation phase will be our main concern in this article.

Parsing/Compilation happens in 3 basic stages:

Tokenizing/Lexing: consider var a = 7; the program will likely to break this up into tokens: var a = 7 ;
Parsing: turn tokens into an Abstract Syntax Tree (AST)

<VariableDeclaration>            var
    <Identifier>                  a
        <AssignmentExpression>    =
            <NumericLiteral>      7

Code generation: take the AST and turn it into a set of instructions to actually create a variable called a and assign a value to it

Note: JS compilation only happens milliseconds right before the code is executed.

How do we know that compilation happens in 2 phases?

There are 3 cases that you can see that JS will handle your programs in at least 2 phases: parsing/compilation ⇒ execution

Syntax errors
Early errors
Hoisting

Case 1:

Consider:

const foo = 'cat'

console.log(foo)

const error = #7'dog' // Throw a syntax error here

If you run this code, you can observe that the program will throw the error first instead of logging 'cat' to the console.

This example shows that JS engine know about the syntax error on the third line before executing first and second line, by parsing the entire program before executing it.

Case 2:

Consider:

'use strict'

console.log('cat')

function saySomething(pet, pet) {
    console.log(pet)
}

saySomething('dog', 'fish') // Uncaught Syntax error: Duplicate param name not allowed

Again here, how can JS engine throw the error without logging 'cat' to the console first? The answer is the code must be fully parsed before any executions happen.

Note: duplicate param name is not allowed in strict mode, but it's allowed in non-strict mode.

Case 3:

Consider:

function myPet() {
    var dogName = 'Doggy';
    {
        dogName = 'Bata'; // error
        let dogName = 'Lucky'; 
        console.log(dogName)  
    }
}

myPet() 
// ReferenceError: Cannot access 'greeting' before
// initialization

Technically, the error is thrown because dogName = 'Bata' is accessing variable dogName before it's declared on the next line.

But why it does not access the variable var dogName rather than accessing the let dogName ?

The only way JS engine would know is that:

JS processes the code first ⇒ comes to the statement let dogName = 'Lucky' ⇒ declare the a blocked-scope ⇒ set up all the scopes and their variable associations.

As you can see now:

JS code is parsed before any execution
Scope is determined as the program is compiled, and will not change during run-time.

Lexical scope

If you declare a variable with var inside a function ⇒ the compiler handles this declaration as it's parsing the function ⇒ associates the variable with function's scope (the variable is accessible anywhere inside the function) .

If you declare a variable with let or const ⇒ compiler handles this declaration ⇒ associates the variable with block's scope (variable is accessible inside the nearest {...} rather than its enclosing function).

While scopes are identified during compilation, they're not actually created until runtime.

The scope of one variable, function or block cannot be changed later.

Summary

Compilation is a set of steps that process the text of your code and turn it into a list of instructions that computer can understand.

JS code is processed in 2 phases: Parsing/Compilation and Execution

The Parsing/Compilation phase only happens in microseconds right before the code is executed

Scopes are identified during compilation

Lexical scope is controlled entirely by the place where functions, blocks, variables are declared

Thank you for your time.

A super-easy way to determine 'this' in JavaScript

Kelvin — Mon, 24 May 2021 01:58:54 +0000

this is one of the fundamental concepts in JavaScript but it's also one of the most confusing concepts to wrap your head around as well. In this blog, I want to share with you the ways that I use to determine what this is.

Before going to deep-dive into all the specific rules that can be applied to determine this, you can remember an easy rule that can be true in most (not all the time) cases. This is how I remember it:

this bound to object when the function is a method of an object.
this bound to global object or undefined when the function is not a method.

You can try to think about these 2 rules when you are going through all the examples.

Rules for binding this :

Default binding

In this rule, we will consider the most common case when calling a function: standalone function invocation.

Consider this code:

function foo() {
    console.log(this.a)
}

var a = '2' // If we declare var in global scope => there will be a property with the same name in the global object. 

foo() // 2 => Foo is called within the global scope

In this example foo is called within the global scope so this will be binded to the global object.

Note: this rule does not apply in 'use strict'.

Implicit binding

Another rule is: does the call-site have a context object.

Consider:

function foo() {
    console.log(this.a)
}

const object = {
    a: 42,
    foo: foo
}

object.foo() // 42

So foo is a method of object then the implicit binding rule says that this should be binded to the object.

Only the top/last level object matters to the call-site (where the function is called):

function foo() {
    console.log( this.a );
}

var obj2 = {
    a: 42,
    foo: foo // for stays in obj2 => obj2 will be the call-site for foo
};

var obj1 = {
    a: 2,
    obj2: obj2
};

obj1.obj2.foo(); // 42

Implicit lost

Whenever we pass our function as a callback function, we will lose the binding of this, which usually means it fallbacks to the default binding (global object or undefined).

function foo() {
    console.log( this.a );
}

var obj = {
    a: 2,
    foo: foo
};

var a = "oops, global"; // `a` also property on global object

setTimeout( obj.foo, 100 ); // "oops, global"

In this example, foo is passed as a callback so this will bound to the call-site where setTimeout is called.

Or:

function foo() {
    console.log( this.a );
}

var obj = {
    a: 2,
    foo: foo
};

var bar = obj.foo; // function reference/alias!

var a = "oops, global"; // `a` also property on global object

bar(); // "oops, global"

In this example, bar is pointing to the foo function, so when we call bar() the call-site will depend on where bar is called, which is the global object in this example.

Explicit binding

Use call and apply

Consider:

function foo() {
    console.log( this.a );
}

var obj = {
    a: 2
};

foo.call( obj ); // 2

The differences between these two are **"C for comma, A for array", which means that you can do:

foo.call(obj, arg1, arg2, arg3)

foo.apply(obj, [arg1, arg2, arg3])

Hard Binding

The implicit lost problem can be solved by doing this, called hard binding

function foo() {
    console.log( this.a );
}

var obj = {
    a: 2
};

var bar = function() {
    foo.call( obj );
};

bar(); // 2
setTimeout( bar, 100 ); // 2

// `bar` hard binds `foo`'s `this` to `obj`
// so that it cannot be overriden
bar.call( window ); // 2

This is such a common pattern, it's provided with built-in util in ES5: Function.prototype.bind

function foo() {
    console.log( this.a );
}

var obj = {
    a: 2
};

var bar = foo.bind(obj)
bar() // 2

In ES6, functions provide an optional parameter called "context" which is a work-around for people not to use bind() :

function foo(el) {
    console.log( el, this.id );
}

var obj = {
    id: "awesome"
};

// use `obj` as `this` for `foo(..)` calls
[1, 2, 3].forEach( foo, obj ); // 1 awesome  2 awesome  3 awesome

`new` binding

Consider:

function foo(a) {
    this.a = a;
}

var bar = new foo( 2 );
console.log( bar.a ); // 2

By calling foo(..) with new in front of it, we've constructed a new object and set that new object as the this for the call of foo(..).

Determining `this`

Is the function called with new (new binding)? If so, this is the newly constructed object.
var bar = new foo()
Is the function called with call or apply (explicit binding), even hidden inside a bind hard binding? If so, this is the explicitly specified object.
var bar = foo.call( obj2 )
Is the function called with a context (implicit binding), otherwise known as an owning or containing object? If so, this is that context object.
var bar = obj1.foo()
Otherwise, default the this (default binding). If in strict mode, pick undefined, otherwise pick the global object.
var bar = foo()

Exceptions

Ignore this

If we pass null or undefined to call, apply or bind , those values are effectively ignored, and the default binding rule will be applied here.

function foo() {
    console.log( this.a );
}

var a = 2;

foo.call( null ); // 2

Note: to be safe in case you want to bind this against the function call which comes from a library or a framework, and that function does make a this reference. You can accidentally point this to the global object.

Safer this

Instead of passing in a null we can pass in an empty object by doing Object.create(null)

You may wonder what the differences are between {} and Object.create(null)?

{}: has the Object.prototype.

Object.create(null) is really an empty object, it has nothing so it's considered to be cleaner.

Softening binding

So if you remember hard binding, it's not really flexible as it only points to the specified obj

const foo = bar.bind(obj) // this always bounds to obj

We can construct an alternative utility that works similarly to bind() called softBind().

if (!Function.prototype.softBind) {
    Function.prototype.softBind = function(obj) {
        var fn = this,
            curried = [].slice.call( arguments, 1 ),
            bound = function bound() {
                return fn.apply(
                    (!this ||
                        (typeof window !== "undefined" &&
                            this === window) ||
                        (typeof global !== "undefined" &&
                            this === global)
                    ) ? obj : this,
                    curried.concat.apply( curried, arguments )
                );
            };
        bound.prototype = Object.create( fn.prototype );
        return bound;
    };
}

The way I remember it is softBind(obj) only fallbacks to the obj if the default this is global object.

Let's see the usage of softBind()

function foo() {
   console.log("name: " + this.name);
}

var obj = { name: "obj" },
    obj2 = { name: "obj2" },
    obj3 = { name: "obj3" };

var fooOBJ = foo.softBind( obj );

fooOBJ(); // name: obj

obj2.foo = foo.softBind(obj);
obj2.foo(); // name: obj2   <---- look!!!

fooOBJ.call( obj3 ); // name: obj3   <---- look!

setTimeout( obj2.foo, 10 ); // name: obj   <---- falls back to soft-binding

Lexical this

Consider:

function foo() {
    setTimeout(() => {
        // `this` here is lexically adopted from `foo()`
        console.log( this.a );
    },100);
}

var obj = {
    a: 2
};

foo.call( obj ); // 2

When you are using the arrow function, that function will bound to whatever foo's this is at its call-time.

Summary

There are 4 rules to determine this:

Using new? Use the newly constructed object
Using call, apply, bind? Use the specified object
Method of an object? Use that object
Default: global object and undefined in strict mode.

In most cases, you can just remember:

this bound to object when the function is a method
this bound to global object or undefined when the function is not a method.

P/s: If you want to read more post about JavaScript or React, please visit my website: https://kelvinnguyen97.com/blog

[Junior Dev] My experiences during my first job as a developer.

Kelvin — Fri, 20 Dec 2019 00:27:10 +0000

Introduction

I am very lucky to get my first job as a software developer when just graduated from my University. Being in a company and the most importantly, first professional experience as a developer was very exciting for me. There are several difficulties that I encountered and also many things that I've learned from them as well.
I really want to share my first experiences with everyone who is going to start their first job, and wish everyone who is looking for a job will receive good news in a near future. 😊

Experiences

First of all, as a junior developer without any professional experiences, when I first looked at the code base that I will need to work on, I was a little bit panic as it was so so massive with thousands and thousands line of codes, and I bet it may had been taken me a few sleepless nights to finish reading through everything, and maybe a couple of months to understand all of them. Surprisingly, when I started doing my tasks, I realised that the more and more I interacted with the code, the more it got familiar to me. Luckily, I worked with a very nice team leader, he would help me with all of mine stupid questions and my problems without any complains.

=> So that when you just started your first job, you may afraid of asking questions or bringing out your opinions about something. Please do not hesitate to ask and tell people what you are thinking, it can help you to go through your problem which take you so much time and you realise that it may just took a minute to solve it. Senior developers or your team leader had a time being a junior dev like us as well, so I think they will understand what we are going through and struggling with. Moreover, the way the solve the problem is also a thing that we could learn as well.

It may sound very easy to ask questions or speak out loud our opinions about something or what you want to change or even ask for what you need in order to work better, but it actually hard sometimes to ask people because we may think that we would interrupt them or they would be annoyed by our stupid questions (it happened to me many times 😅!!). It may have some negative effects on your mood and motivation to go to work so just speak to people in your team or whoever that can help you, I am sure you will be very happy to see your ideas or opinion got accepted and turned to something helpful for everyone.

Conclusion

The article is going be a bit long so I just stop here even-though I really want to share much more than that. If anyone has any experiences and things to share please comment below, I would love to know what you think about doing the first dev job and difficulties that you are facing.
Finally, I wish everyone has a lovely Christmas with your loved one and family, and a wonderful new year 2020!!! ❤️

[Junior Dev] Step by step through a coding challenge. (Part 1)

Kelvin — Sun, 20 Oct 2019 11:48:20 +0000

About me

My name is Kelvin, a graduate software developer. This is one of my first blogs ever. These are all the things that I learned and I want to share it with everyone who is going to have an interview or just simply want to know about it.

Introduction

A whiteboard challenge in an interview is always a nightmare for beginners like me. I just got my first technical interview ever last week, and I was totally panic when I took a first look at the question and could not do it properly. After that, I decided to study how to manage to solve a whiteboard problem in the right way.

15 Steps to go through a problem

With these 15 steps, I believe you can impress the interviewers with your critical thinking of how you approach and solve a problem.

Some small tips

Do not jump straight to into coding.
Calm down, do not be panic even though you may not know how to code the answer, just speak out the approach to the problem that first comes to your mind (follow the steps).
A thank you email after the interview may give you a bonus.
Confidence is a key, I know you can totally get this done.

Conclusion

I hope this little post helps you get an idea of how to prepare and go through a whiteboard challenge. The coding challenge is always a trouble and a nightmare of every junior developer (or at least for me). But be confident and believe in your self, I wish you guys all the best with your coding challenge.

Bonus:

I really like the video demo of the technical interview at Google. It may give you an idea and how they work through a problem. Moreover, try to apply the steps above to the video, it will make more sense when we apply it to a real problem.
Link: https://www.youtube.com/watch?v=XKu_SEDAykw&t=1267s

Forem: Kelvin

Deep dive JavaScript: Scope

What is Compiled and Interpreted?

Step by step through compilation phase

How do we know that compilation happens in 2 phases?

Case 1:

Case 2:

Case 3:

Lexical scope

Summary

A super-easy way to determine 'this' in JavaScript

Default binding

Implicit binding

Explicit binding

new binding

Determining this

Exceptions

Summary

[Junior Dev] My experiences during my first job as a developer.

Introduction

Experiences

Conclusion

[Junior Dev] Step by step through a coding challenge. (Part 1)

About me

Introduction

15 Steps to go through a problem

Some small tips

Conclusion

Bonus:

`new` binding

Determining `this`