DEV Community: Akansh Saxena

this with arrow functions in JS

Akansh Saxena — Mon, 12 Sep 2022 18:49:32 +0000

Hello reader, this has always been one of the most confusing topics in JavaScript. If you have some previous knowledge of programming languages like Java, then understanding this would again be a much more difficult task because your mind will have to fight between your existing knowledge of this in other languages and learning new concepts in JavaScript even though they don't overlap at all.

Along with various other features and enhancements, ES6 brought arrow functions with it, and with the arrow functions introduction, the concept of this started having a few more tweaks. To understand its concept and behaviour with arrow functions, some previous understanding of this is definitely required. So, feel free to pause here and get some understanding of this and then jump back to the topic.

What are arrow functions?

Along with various other features, ES6 brought arrow functions with it too. They are newer, easier, and much cleaner ways of writing a function. They reduce the lines of code required to declare a function and come with small differences from the normal function declaration.
Let's compare the normal and arrow function declaration syntax first.

//normal function
function foo1(){
    return null
}
//arrow functions
const foo2 = () => {
    return null
}
//this can further be written in much simpler way
const foo = () => return null

As we see, arrow functions have much simpler syntax but the major difference is that arrow functions don't create their own binding but take up the binding of their parent object i.e. they inherit it from the parent scope (remember, the parent should be a non-function). To make it simpler, the arrow functions follow the same this behaviour as it is in their parent.
For normal functions, it totally depends on how and where they are called but for arrow functions, it depends on where they have been defined. In the above example, if we console this inside both the functions then both this will have a global object in them but the reason is quite different. Let's explore the same in next section.

Understanding this behaviour with arrow functions

this behaviour in arrow function can vary in different scenarios so let's break it into smaller parts and look through them.

In normal declaration

//normal function
function foo1(){
    console.log(this)
}
//with arrow functions
const foo2 = () => {
    console.log(this)
}

foo1()
foo2()

We saw in the above scenario, both consoles will print a global object(window object in case of browsers). Function foo1() is declared in a global context and is called in a global context, which is a normal function call. This means that the object calling foo1() is a global/window object(foo1() can also be called as a window.foo1()) and therefore, this in having a value of the global object and hence, for a normal function call, this always points to object calling that function. Whereas, foo2 has been declared in a global context whose this always points to a global object and hence, in arrow function this takes up the value of its parent binding, here global context and points to global/window object.

Defined inside a global object

//normal function
const obj1 = {
foo1 : function(){
        console.log(this)
     }
}
//with arrow functions
const obj2 = {
foo2 : () => {
        console.log(this)
     }
}

obj1.foo1()
obj2.foo2()

To call the normal function(foo1) inside obj1, we need to first access obj1 and then call foo1 through it. Hence, foo1 is not a normal function call and it has to be called through obj1. obj1 is an object and has created its own binding(this) and calling foo1 through obj1 makes this inside obj1 to have all properties of obj1 only and not global/window object. Whereas, if we look at obj2 and foo2, then even though foo2 is declared as a key inside obj2 but still it will have a value of this inherited from its lexical scope i.e. obj2 because as defined earlier, arrow functions inherit this property from their parent and here obj2, which is parent object to foo2 has been declared in global/window context which has this binding to global/window context and therefore, passes same this (global/window) to foo2.

In nested function call inside an object

//normal function call inside a method
const obj1 = {
        foo1 : function(){
                function foo2(){
                        console.log(this)
                }
                foo2()
        }
}
obj1.foo1()
//arrow function call inside a method
const obj2 = {
        foo3 : function(){
                const foo4 = () =>{
                        console.log(this)
                }
                foo4()
        }
}
obj2.foo3()

If you look closer at the code, then you can guess the output for both consoles as it has already been explained in the above two points. If you have taken a guess and it comes to be the same as what we will discuss, then congratulations to you.

So, in foo2 the console will print the global/window object and the reason is in the definition above, any normal function call will always point its this to the global/window object. Here, foo1 is a method to obj1 but foo2 is a normal function declared inside this method and hence this pointing to global/window object. In the second scenario, foo4 is an arrow function that takes up the this from its lexical scope so here, foo4 is lexically scoped to foo3, and foo3's this is pointing to obj2 object, and hence foo4 will also point to obj2.

Here comes an interesting question. What if, foo3 is assigned with an arrow function instead of a normal function?

const obj2 = {
        foo3 : () => {
                const foo4 = () =>{
                        console.log(this)
                }
                foo4()
        }
}
obj2.foo3()

In this case, it is certain that foo4 will always take up its this value from the parent non-function which in this case is obj2, and since, obj2 is a global object whose binding is to a global object and hence foo4's this will also point to global/window object. So, we can see a drastic change in the behaviour of functions depending if they are normal or arrow functions.

Global functions bind to an object

//normal function
function foo1(){
        console.log(this)
}
const obj1 = {
        name: 'Akansh'
}
const foo2 = foo1.bind(obj1)
foo2()

//arrow function
const foo3 = () => {
        console.log(this)
}
const obj2 = {
        name: 'Akansh'
}
const foo4 = foo3.bind(obj2)
foo4()

The given examples are no different from what we have seen earlier in the above examples. The only difference is that a global function is created which is now bound to another object and hence, the functions will now be treated as they were declared inside the object.

foo2 carries foo1 bind to obj1 and hence, calling foo2() is just like calling obj1.foo1()(if foo1 was declared inside obj1) and therefore, foo2 will have its this pointing to obj1 only. Similarly, foo4 carries foo3 bind to obj2 but here foo4 this points to global/window object because we now know that arrow function inside the object will have this pointing to object's binding and here its global/window object.

Conclusion

For a normal function call, this will always point to global/window object. A normal function defined inside an object will always takes up this from the object written on adjacent left in the dot notation. Example:

const obj = {
    foo : function(){
         console.log(this)
    }
}
obj.foo()
//here, obj is the object calling foo and is on the adjacent left while writing in dot notation

For arrow function, the simplest explanation will be, this will always inherit binding from its non-functional parent. If defined in global context, then this in arrow function points to global/window object only.

I believe that the explanation was of some help to you and provided some value. If there is something I might have missed or you would like me to address or if there are some suggestions, feel free to comment and reach out.

What actually is Virtual DOM?

Akansh Saxena — Mon, 19 Jul 2021 14:40:57 +0000

Hello Reader, recently I encountered a but obvious question from an interviewer, "What exactly is Virtual DOM?". For the next five minutes, I was explaining how it works and why is it efficient but this didn't answer the question asked. If you are already working with ReactJS or are new to it then you surely would have encountered the same question a gazillion times but unfortunately, not all of us have a clear understanding of what a virtual dom is.

I then read a couple of articles, ReactJS documentation and watched a few videos, and came up with an understanding of Virtual DOM. Hence, I will try to give a proper explanation of what is a Virtual DOM and how does it help in the faster rendering of components.

What is DOM?
What is Virtual DOM?
How do rendering components work with Virtual DOM?

What is DOM?

If you are coming to learn about Virtual DOM, you definitely would be knowing DOM, but to give a small gist we will go through it. It is perfectly fine to skip this part.

The Document Object Model(DOM) is a structured model representation of HTML and XML documents. In simple words, the elements present on a webpage can be viewed in form of a tree, where the nodes are parent HTML tags and the branches include their respective children tags.

Consider this example of a form visible on a webpage:

The DOM of this form will look like this:

Yes, the DOM is actually similar to the HTML one must have written for the form. Then how is DOM different from any HTML document? HTML is what the server sends in response to a request whereas DOM is built by the browser on top of the HTML received. The key difference still being that DOM is a model of a document that has various APIs through which we can manipulate the HTML over time.

What is Virtual DOM?

Now, since we have an understanding of DOM, so let's dive deep into the world of Virtual DOM.

Here we will try to explore Virtual DOM using React components because what's better than finding an answer in the question itself.

We will now create a simple React functional Component and further instead of rendering it, we will just try to log it in the console:

const DummyComponent = ({title}) =>{
    return(
           <div className="container">
                  <h1>{title}</h1>
                  <h3>This is a dummy component</h3>
           </div>
    )
}

console.log(DummyComponent("Calling the dummy component"))

Now check what has been logged in the console. Kaa-Boom 💥, an object has been logged that has all the details of the component you just created. Have a look at the object and its keys, the props key contains the children's elements along with the other props passed to the component. This is what a Virtual DOM looks like.

By definition, a virtual DOM object is a representation of a DOM object, like a lightweight copy. So, now we can understand this definition more clearly. Virtual DOM is an object representation of the actual DOM rendered, it has all the DOM properties but is only present in the memory and cannot impact what gets rendered on the webpage.

Manipulating Virtual DOM is faster as compared to manipulating the actual DOM, the reason being that the Virtual DOM is only present in memory and can easily be created or deleted.

Note: To get more clarity on the object logged, you can refer to this video.

How do rendering components work with Virtual DOM?

Now that we have a basic understanding of DOM and Virtual DOM, we will have a look at the differences between the process of rendering elements using DOM and Virtual DOM.

In simple DOM manipulation, let's say we want to handle the click event for any button <button id="btn">Click me!</button>, then we first need to have access to this element using the getElementById('btn'), this method will traverse through the complete DOM and will find the element with the specific ID and then will perform the DOM manipulation using other traversing cycle. This process is simple if we have to deal with a small number of elements but let's say we have an application to view stock market trends, prices of various stocks, and related news, now in this application, we have thousands of components, the data inside them may change a couple of times within a second, and so handling this using simple DOM manipulation technique might be a tedious and time taking task. To overcome this drawback, React uses Virtual DOM for its DOM manipulation process.

In React, every component keeps an eye on its state and other parameters on which rendering of that component depends. Let's say that in our component there is a state change and re-rendering of the component is required, here the Virtual DOM comes into the picture, the whole process involved in rendering is as follows:

At the initial step, React will take a snapshot of the actual DOM currently present (DOM present before the re-render happens) and will store it in the memory, for now, we can call it Real Virtual DOM.
Now, React will create a new Virtual DOM from scratch which has all the old components plus the new change, this means React doesn't know the previous DOM. It will consider all its components as new. The new Virtual DOM created is kept separate from the old Virtual DOM and doesn't do any change to the actual DOM.
In the third step, React will compare both the Virtual DOMs and will find out the new change that has to be implemented and its position. This comparison is done using the "Diffing Algorithm" and the process is called "diffing". There is a whole lot that does behind the scenes while performing diffing, you can learn more about it here.
Once the change has been detected, React will now remove the old component from the actual DOM and paint this new component onto the actual DOM. This process goes like, firstly the component that has to be removed receives componentWillUnmount() lifecycle method which removes it, after this the new component that has to be pained receives componentWillMount() and componentDidMount() that brings the new component to the frontend. This process of syncing Virtual DOM to the real DOM is acknowledged as Reconciliation.

This completes the workflow of Virtual DOM. This might seem a time taking process because it involves few crucial steps, but remember most of these steps are being executed in Virtual DOM which is basically objects stored in the memory until the last step where we truly need to change the actual DOM.

So, this sums up the Virtual DOM and how it helps React in rendering components. If there is something that I missed or you would like to add then please provide your valuable feedback. Also, if there is anything you would like me to write about in the future then please let me know.

P.S. Trying my hands at writing for the first time.