DEV Community: Vasil Vasilev

How the `.then()` method interacts with the JavaScript event loop.

Vasil Vasilev — Sat, 30 Mar 2024 16:28:35 +0000

Async via Web APIs

Why do we need them? So that we can have non-blocking operations. We have our code and javascript executes synchronously so what if we need to fetch some data on a remote server. Execution stops until the data is fetched. That is hardly efficient. We rely on the Javascript environment that gives us Web APIs to make async non-blocking operations possible. One popular option to do this fetching of data and no block the main thread is via Fetch API. But what actually happens underneath.

Promises

To understand what happens underneath, I will use a more simple API -> setTimeout in conjunction with Promise, since the same process is relevant for any other Web API. We rely on setTimeout to extract the callback we pass into it from the call stack (main thread) so as to not block it until some moment in the future (with setTimeout we know the minimum amount of time this moment will expire in).

Consider the following example for any future reference:

new Promise((resolve) => {
    setTimeout(()=>resolve('Done!'), 100);
})
    .then(result => console.log(result))

The function we pass into the setTimeout is actually the resolve of a Promise. So, in effect, we want the promise to be resolved after the setTimeout is executed (meaning being extracted from the main thread, set as a macroTask, await the clearing up of the main thread and finally re-introduced and executed in the main thread). To truly understand Promises, you have to understand the connection between resolve and .then().

[[PromiseFulfillReactions]]

Promises in JavaScript represent an eventual completion (or failure) of an asynchronous operation and its resulting value. The [[PromiseFulfillReactions]] and [[PromiseRejectReactions]] are internal properties of a Promise that hold the functions (handlers) to be executed when the Promise is fulfilled or rejected.

The [[PromiseFulfillReactions]] has among others a PromiseReaction field with [[Handelers]], meaning what we put in the .then(). This field gets triggered when the promise is fulfilled. When does the promise get fulfilled -> when the acync operation that was in the task Queue gets pack in the call stack and is executed.

So basically, we have an async operation (setTimeout), that async operation has the resolve of the Promise. When the async operation gets back into the call stack and gets executed, the resolve of the promise gets executed.
Namely, the Promise becomes fulfilled and it triggers the PromiseFullfillReaction Handler (which is the code inside .then()). result => console.log(result) is set onto the microTask Queue until the call stack is free and when it is free, it finally gets the actual parameter 'Done!' applied to be executed.

Why we need event capture and event bubbling?

Vasil Vasilev — Sat, 09 Sep 2023 11:52:22 +0000

Since events are a fundamental part of any web application, we need a way to manage those events and interconnect them to form a whole web page. The structure of any web page is represented by the DOM tree, so this is also the chain that serves as a link between nodes/elements which can fire events. Looking at the DOM tree and knowing that Javascript initial purpose was to be scripting language for static web sites, we can infer why is Javascript's inheritance based on the prototype model. It two interconnects via a chain of objects that each have a prototype which in turn is also an object. A DOM tree is similar with its elements that consists of properties and methods, but also of links to parent and children elements.

But to go back to the subject matter of the current article, the two event propagation models through which we manage and control the flow of events in the Document Object Model (DOM) are event bubbling and event capture.

So, what happens when we click on a button on a web page?

Capture

Well, we would have to first open the root element -> window object, then document, then html then down the tree to the event that actually triggered the event. This is also called the capture phase, we capture the event triggering element.

Bubbling

The reverse flow is named the bubbling phase. From the event.target to the outermost layer of the DOM tree.

But why do we need them both? Is it not enough to 'capture' the element that triggered the event and save resources on bubbling?

The reason for needing both capture and bubbling is that in reality, we rarely have one element with one event handler.

So, what if we click on a button that is within a div and both of them have an event hanlder? The capture phase will go top-down and trigger the event handler of both the target element - the button and its parent element - the div. We do not want that. We want isolation of event handling. Thus, we need the capture phase to reach the target element, but also a bubbling phase from that very target element up to the top, to have control over the event propagation.

e.stopPropagation()

To do this, we apply the e.stopPropagation() method at the top of our event handling function (event obviously passed in as a prop), so that we stop the propagation from going up the parent elements of the target element.

const Example = () => {
    handleCallFarm() {
        console.log("Hello, whole farm");
    }

    handleChicken() {
        console.log("Hello, chicken!");
    }

    handleCows() {
        console.log("Hello, cows!");
    }

    handlePigs(event) {
        event.stopPropagation(); // USED HERE!
        console.log("Hello, pigs!");
    }

    render() {
        return (
            <div className="parent-element" onClick={handleCallFamily}> 
                <button className="child-element" onClick={handleChicken}>Call Chicken</button>
                <button className="child-element" onClick={handleCows}>Call Cows</button>
                <button className="child-element" onClick={handlePigs}>Call Pigs</button>
            </div>
        );
    }

}

So if we click:

Call Chicken -> we will print: "Hello, chicken!" "Hello, whole farm"
Call Cows -> we will print: "Hello, cows!" "Hello, whole farm"

BUT if we click:

Call Pigs -> we will print only: "Hello, pigs!"

That is because we stopped the propagation from going up the parent element. Thus, the most popular use case of the bubbling phase -> event delegation.

Event Delegation
Bubbling is essential for event delegation, which is a powerful technique to optimize event handling. By attaching a single event listener to a common ancestor of multiple elements, you can efficiently handle events for all those elements without adding individual event listeners to each one.

As we have come to understand now that would not be possible with capture alone, because we will always have both the parent and the child event handler firing. However, with bubbling, we start from the child and have the capability of stopping further propagation, which enables us to reduce the amount of event handlers by having only one on the parent element. Thus, we both have less event handlers, but also we do not loose our control to precisely target the child element.

Simply said, we have a child element that triggers an event without the need for handler. Its parent, tho, has a handler, and since bubbling goes up the DOM tree, we intercept the event coming from the child at the parent level.

An important additional take from this article is the difference between event.target and event.currentTarget. They help illustrate the significance of element that cause the event and element that has an event listener attached to it.

Event.target vs Event.currentTarget

event.target is the most deeply nested element that caused the event.
event.currentTarget is the element that listens to the event (where the event listener is attached to).

const Example = () => {
    handleCallFarm() {
        console.log("Hello, whole farm");
    }

    handleChicken(event) {
        console.log("Hello, chicken!");

        console.log("event.target:", event.target);
        console.log("event.currentTarget", event.currentTarget);
    }

    handleCows() {
        console.log("Hello, cows!");
    }

    handlePigs() {
        event.stopPropagation(); // USED HERE!
        console.log("Hello, pigs!");
    }

    render() {
        return (
            <div className="parent-element" onClick={handleCallFamily}> 
                <button className="child-element" onClick={handleChicken}>Call Chicken</button>
                <button className="child-element" onClick={handleCows}>Call Cows</button>
                <button className="child-element" onClick={handlePigs}>Call Pigs</button>
            </div>
        );
    }

}

So if we click:

Call Chicken -> we will print: "Hello, chicken!" "event.target:", Call Chicken "event.currentTarget", Call Chicken

BUT if we click:

Call Chicken, yet this time target and current target are attached to the parent element: "Hello, whole farm!" "event.target:", Call Chicken "event.currentTarget",

const Example = () => {
    handleCallFarm() {
        console.log("Hello, whole farm");

        console.log("event.target:", event.target);
        console.log("event.currentTarget", event.currentTarget);
    }

    handleChicken(event) {
        console.log("Hello, chicken!");

    }

    handleCows() {
        console.log("Hello, cows!");
    }

    handlePigs() {
        event.stopPropagation(); // USED HERE!
        console.log("Hello, pigs!");
    }

    render() {
        return (
            <div className="parent-element" onClick={handleCallFamily}> 
                <button className="child-element" onClick={handleChicken}>Call Chicken</button>
                <button className="child-element" onClick={handleCows}>Call Cows</button>
                <button className="child-element" onClick={handlePigs}>Call Pigs</button>
            </div>
        );
    }

}

Javascript is single or multi-threaded?

Vasil Vasilev — Thu, 07 Sep 2023 14:33:40 +0000

Javascript is a synchronous programming language. But it is also the language of the Web which requires asynchronous fetching of data, also we want user interactivity, namely, functions that are event driven and executed based on user behavior only.

Callbacks and Promises

We achieve this by creating pieces of code that do not execute immediately when the program initializes. Those pieces of code are also known as callbacks and promises. Initially, the most basic approach was with pure callbacks, but the very nature of function definitions lead to the so called 'callback hell' of nested callbacks. Thus, a more refined tool emerged - a promise. Nowadays, we also have the async/await as a popular alternative to the '.then()' resolving of promises. However this article's purpose is not to educate on the basics of dealing with asynchronous requests.
It attempts to delve into the nature of Javascript and explain how come asynchronous tools such as callbacks and promises are part of it.

So how come a single-threaded programming language have asynchronous tools at its disposal?

Javascript runtime

The straightforward answer is - Javascript runtime. Nowadays, Javascript is not only a scripting language with the simple purpose of toggling a button on a static web page, it a fully capable programming language. Thus, to understand how a single-threaded language can achieve concurrency, let's start with the following image.

We see a JS engine and a few additional features - Web API, Event loop and a Queue. When we say single thread, we refer to the JS engine. Simply said, this relates to the code you have written and its execution contexts, while the additional features 'create' an additional thread. So, the runtime consists of two parts - your code and some other external code both producing the whole application. So, modern Javascript always needs a runtime environment to execute and the most popular one is the browser. Another popular one is Node.js.

But now, let's look at the mechanism of a callback function, applying what we have learned about runtime environment already.

Callbacks

function fetchData(callback) {
  setTimeout(function () {
    const data = 'Async data';
    callback(data); // Execute the callback function with the data
  }, 1000);
}

function processData(data) {
  console.log('Received data: ', data);
}

fetchData(processData); // Pass the processData function as a callback
console.log('Fetching data...');

The Line of Execution:

console.log('Fetching data...'); // This line is executed first.
console.log('Received data: Async data'); // This line is executed second.

A Step by Step Explanation:

fetchData(processData) is triggered first
setTimeout is called with a delay of 1000 milliseconds.
While waiting for the timeout, the program continues by executing console.log('Fetching data...');
After 1000 milliseconds (1 second), the callback function processData is executed with the data 'Async data'.
Inside processData, the statement console.log('Received data:', data); is finally executed.

So, the final order of printing statements is:

"Fetching data..."
"Received data: Async data"

Thus, the "Fetching data..." console.log executes before the fetchData function.

How is this possible?

How does Javascript, which is single-threaded, 'know' to continue interpreting the code and execute the subsequent console.log("Fetching data..."), even though it has another task seemingly on standby (fetchData function).

As I said, when we say single-threaded, we refer to the execution mechanism of the JS engine. The Javascript engine is responsible for the execution contexts, namely, managing the memory heap and the call stack. The memory heap stores all the variables defined in our JS code while the call stack performs the operations (function execution).

So, back to the current problem, single-threaded means only one call stack. One call stack, in turn, means only one piece of code can be executed at a time.

In our case with console.log('Fetching data...') and fetchData function, given the nature of Javascript to be non-blocking, Javascript does not wait for the response of the callback, but moves on with the interpretation of the subsequent blocks of code.

Why does it not wait?

The answer - the callback fetchData function is 'extracted' from the call stack of the current main thread and logically the execution continues with console.log('Fetching data...').

But where is this callback 'extracted' to?

The general answer not only for callbacks is that any such asynchronous function utilizes the Web API by relying on the Event loop to manage its queue priority when to re-enter the main thread call stack.

In the case of callbacks, the Timer Web API executes the setTimeout and the Event loop puts the result of that function in the Tasks Queue. That is also why the delay set in setTimeout is known as a minimum delay time. It is unclear when exactly the call stack will be freed up so that a new event cycle can be executed and tasks from the queue be added to it.

Let's now look at how promises are resolved in the Javascript runtime.

Promises

const promise = new Promise(resolve=>{
  resolve("Promise")
}, reject => {

})

promise.then(res=>console.log(res))

In the case of promises, the promise is set into the Microtask Queue which the event loop ranks with higher priority than regular tasks such as setTimeout callbacks. Meaning when/if a promise is fulfilled, its result is added to the microtask queue, ensuring that it will be executed before the next (regular) task in the event loop.

Inversion of control

Thus, with simple words, the Javascript runtime adds threads and concurrency to the otherwise, single threaded programming language.

That would also be known as inversion of control, a very popular term in programming. The code result becomes dependant on an external factor, namely, the additional features that come with every Javascript runtime. Control of execution is inverted and handed over to an external entity as described above. In

The Importance Of Immutability In React

Vasil Vasilev — Thu, 24 Aug 2023 11:25:51 +0000

Immutability is a crucial concept in React. It refers to the practice of not changing the original data structures once they are created. Instead, when modifications are required, new data structures are created to represent the updated state.

Why is immutability manually applied?

In JavaScript, objects and arrays are reference types. When you mutate an object, its reference remains the same, even if the content changes. This can lead to unexpected behavior when comparing objects for equality or when checking for changes. Immutable data ensures that changes result in new references, facilitating accurate comparison checks.

Why is immutability encouraged in React specifically?

Predictable Data Flow: In React, components re-render when their state or props change. If the data within a component's state is immutable, it becomes easier to predict when a re-render will occur. This predictability is essential for maintaining a stable and efficient application performance.
It improves performance: React uses a virtual DOM to render components. The virtual DOM is a lightweight representation of the actual DOM. When an object is immutable, React can simply compare the old and new objects to see if anything has changed. If nothing has changed, React can skip the rendering step, which can improve performance.
Debugging: It can help to prevent bugs. When objects are immutable, it is more difficult to accidentally modify the state of an object in a way that can cause a bug.

How to achieve immutability in React?

One way is to use the const keyword to declare variables. Variables declared with the const keyword cannot be changed.

// bad: Because a new object is created every time React renders.

function App() {
  const [visible, stop] = useElementVisibility(ref, {
    root: null,
    rootMargin: "0px",
    threshold: 1,
  });
}

const options = {
  root: null,
  rootMargin: "0px",
  threshold: 1,
};

// good: Because the reference to the object remains unchanged.

function App() {
  const [visible, stop] = useState(ref, options);
}

Alternatively, you can choose to use the useMemo function to wrap it.

// good: Because the reference to the object remains unchanged.

function App() {
  const options = useMemo(() => {
    return {
      root: null,
      rootMargin: "0px",
      threshold: 1,
    };
  }, []);

  const [visible, stop] = useState(ref, options);
}

Understanding the useCallback hook

Vasil Vasilev — Wed, 09 Aug 2023 12:45:03 +0000

Official Definition

According to the React official documentation as of the time of writing this article, useCallback is a React Hook that lets you cache a function definition between re-renders.
Thus, we try to achieve efficiency by avoiding re-rendering of unnecessary code that can be memoized.

How does it work?

const cachedFn = useCallback(fn, dependencies)

The useCallback hook takes two arguments: the function to memoize, and an array of dependencies. The dependencies are the values that the function depends on. If any of the dependencies change, the function will be re-run.

Why don't we just store the function outside the component?

We may be tempted to store the function as any other value stored in a variable (in JS, functions are first class functions).

import React, { useState } from 'react';

// Outside the component
function myFunction() {
  console.log('Function executed');
  return 'Function result';
}

function ParentComponent() {
  const [count, setCount] = useState(0);

  return (
    <div>
      <button onClick={() => setCount(count + 1)}>Increment</button>
      <ChildComponent func={myFunction} />
    </div>
  );
}

function ChildComponent({ func }) {
  const result = func();

  return <div>{result}</div>;
}

export default ParentComponent;

In this example, even if you click the "Increment" button and cause the ParentComponent to re-render, the myFunction outside the component won't re-run unless explicitly called. However, if myFunction was used in the rendering logic of the ChildComponent, the child component might re-render if the parent component's re-render caused changes in the prop values.

So, every time the component re-renders, myFunction will be re-run, even if there is no conditional but simply some plain console logging and returning of a string. This can be inefficient, because myFunction may be expensive to run.

The useCallback hook goes a step further in limiting re-renders

The hook limits re-renders to only when one of the dependencies' value change:

import React, { useState, useCallback } from 'react';

// Inside component as a definiton, but actually inside React cache

function ParentComponent() {
  const [count, setCount] = useState(0);
  const myFunc = useCallback(()=>{
     function myFunction() {
        console.log('Function executed');
        return 'Function result';
     }
  },[])

  return (
    <div>
      <button onClick={() => setCount(count + 1)}>Increment</button>
      <ChildComponent func={myFunc} />
    </div>
  );
}

function ChildComponent({ func }) {
  const result = func();

  return <div>{result}</div>;
}

export default ParentComponent;

In this example, the myFunction function will not be re-rendered even if the update of the ParentComponent's state triggers a re-render in the ChildComponent state via the props.

But where is the function stored?

When using the useCallback hook in React, the function is stored outside of the render cycle. The purpose of useCallback is to return a memoized version of the function, meaning that it retains the same memory reference across renders unless one of the variables in its dependency array changes.

So to understand the useCallback hook, you have to understand how exactly it limits re-renders. Thus, one must look into the dependency array.

With simple words, the dependency array plays the vital role to control when it is acceptable to allow re-renders. That would be if a variable that the function depends on, changes its value.

A more complex example would be an onCancel function. This function is part of a personal project of mine - Airbnb clone. It accepts an id of an item and updates the Front-End via update of state and the Back-End via an axios request.

const onCancel = useCallback((id: string) => {
    // del FE
    setDeletingId(id);
    // del BE
    axios.delete(`/api/reservations/${id}`)
        .then(() => {
            toast.success('Reservation cancelled');
            router.refresh();
        })
        .catch((error) => {
            toast.error(error?.response?.data?.error);
        });
}, [router]);

So why do we put the router variable in the dependency array?

The router variable may change between the time we trigger the cancel function and the time the router.refresh() method is called. To ensure that the onCancel function is re-evaluated, we need to add the router variable to the dependency array of the useCallback hook.

The opposite is true for the setDeletingId. It does change a state if you look into the whole code, but this state does not change in any way the variables that the onCancel function depends on.

Therefore, the dependency array is a crucial instrument that must be configured so that the useCallback hook always works with up-to-date variables it may depend on. In a sense, it serves the opposite purpose of useCallback, since it allows for re-renders to happen, so that useCallback can have the most recent data it works with. But it also limits the re-renders up to the sanitary minimum to avoid any waste of resources that complex functions inside component may cause.

Copying an Array in Javascript

Vasil Vasilev — Fri, 28 Jul 2023 16:34:19 +0000

Refer to this visualization of left STACK and right HEAP memory throughout the article:

To understand copying in Javascript, we need to begin with what kind of type we are copying?

A Primitive and an Object.

Primitives are immutable, objects are mutable by default. This relates to the way we store the value in memory.

With primitives we store the value on the Stack, while with objects, we store the value on the Heap. What is stored on the Stack, in the case of objects, is a pointer that refers (thus, the term 'reference') to the memory address of the object value stored on the Heap.

Copying a primitive (Value type)


let value = 3;
let valueCopy = value; // create copy

console.log(valueCopy); // 3

// Change valueCopy
valueCopy = 2
console.log(valueCopy); // 2

// ✅ Original NOT affected 
console.log(value); // 3

Copying an array (Reference type)

let array1 = [1,2,3];
let array1Copy = array; // create copy

console.log(array1Copy); // [1,2,3];

// Change 1st element of the array
array1Copy[0] = 777;
console.log(array1Copy); // [ 777, 2, 3 ]

// ❌Original got affected
console.log(array1); // [ 777, 2, 3 ]

What we did above is just copy the pointer that points to the assigned memory slot in the Heap. Thus, traditional assignment via '=' results in an unwanted behavior. We need to copy the reference in Heap memory and create a whole new reference there.

To achieve this we have two options: Shallow copy or Deep copy

Shallow copy
Def.

Shallow copy is a bit-wise copy of an object. A new object is created that has an exact copy of the values in the original object. If any of the fields of the object are references to other objects, just the reference addresses are copied i.e., only the memory address is copied.

Deep copy
Def.

A deep copy copies all fields, and makes copies of dynamically allocated memory pointed to by the fields. A deep copy occurs when an object is copied along with the objects to which it refers.

Shallow copy
Ex.


let array2 = [4,5,6];
let array2ShallowCopy = [...array2]; // create TRUE copy

console.log(array2ShallowCopy ); // [4,5,6];

// Change 1st element of the array
array2ShallowCopy [0] = 777;
console.log(array2ShallowCopy ); // [777,5,6]

// ✅ Original NOT affected 
console.log(array2); // [4,5,6]

The Shallow copy copies simple objects, meaning they have no nested objects within themselves.

Deep copy
Ex.


let array3 = [7,[8],9];
let array3Copy = structuredClone(array3)); 

// Make some changes
array3Copy [0] = 777; // change shallow element
array3Copy [1][0] = 888; // change nested element
console.log(array3Copy ); // [ 777, [888], 9 ]

// ✅ Nested array NOT affected
console.log(array3); //  [7,[8],9]

The Deep Copy copies objects fully, however, nested they are.

NB
structuredClone() is for objects that are serializable. If they are not serializable, it will fail in the same way that calling JSON.stringify() which was formerly used for deep copying.

Shallow vs Deep

Imagine that nested objects form layers. If we have an array with an element that is also an array, we have 2 layers. A shallow copy means that only the top layer of the object is copied into a brand new memory slot on the HEAP. Any nested layer would be copied 'shallowly' - just as a reference address, without a whole new memory slot on the HEAP for the nested object.

On the other hand, a deep copy makes a copy not only for the top layer, but for all nested layers.

As a rule of thumb, we could say that primitive values can only form a so called top layer. But if we include an object within our array, we automatically nest it as an element, creating a one more layer.

Loose Coupling and Dependency Injection (DI) principle

Vasil Vasilev — Tue, 11 Jul 2023 08:33:02 +0000

What is the Dependency Injection (DI) principle?

The Dependency Injection principle is a software design pattern that promotes loose coupling and high modularity in object-oriented programming.
With simple words, we provide dependencies to a class from the outside rather than create in the class itself.

Instead of this:

class UserService {

  logging(message) {
    console.log(message);
  }

  addUser(user) {
    // Add user logic...
    this.log(`User added: ${user}`);
  }
}


const userService = new UserService(); // Create the UserService

// Usage
userService.addUser("John Doe");

We do this:

// Logger class
class Logger {
  logging(message) {
    console.log(message);
  }
}

// UserService class with Logger dependency
class UserService {
  constructor(logger) {
    this.logger = logger;
  }

  addUser(user) {
    // Add user logic...
    this.logger.logging(`User added: ${user}`);
  }
}

// Creating instances and injecting dependencies

const logger = new Logger(); 
// Create a Logger instance

const userService = new UserService(logger); 
// Inject the Logger instance into UserService

// Usage
userService.addUser("John Doe");

The reason for such an abstraction is to achieve separations of concerns. We want our addUser function to be part of our UserServices class, but our logging function being too fundamental to fix into only one class, should be abstracted away from UserServices class into its own class.

Why? The answer is re-usability. Therefore, we abstract logging function and inject it as a dependency via the constructor.

Constructor

The constructor, thus, is a crucial tool since it not only initialises class properties but also serves as an entrypoint for its class' dependencies on other classes (the UserService doesn't create a Logger instance internally but relies on the Logger instance provided to it).

Summary

We go from thigh coupling (logger function being an integral part of UserService class) to loose coupling (The Logger instance is independent of the UserService, and we can easily replace it with a different Logger implementation without modifying the UserService code), thus, achieving reusability and abstraction.

Mutable And Immutable Values in Javascript

Vasil Vasilev — Mon, 10 Jul 2023 18:48:10 +0000

In JavaScript there are two types of data types - primitive types and objects. Whenever you define a variable, the JavaScript engine allocates a memory to it. It stores all variable names on the Stack, while the values are either on the Stack or on the Heap.

let str = "hello"; 
// str (variable name) is stored on the Stack
// 'hello' (value) is stored on the Stack

let obj = { fname: "Vasil", lname: "Vasilev"} 
// obj (variable name) is stored on the Stack
// {...} the value is stored on the Heap

NB: The { fname: "Vasil", lname: "Vasilev"} is merely a reference which points to the actual value stored on the Heap.

Any data type value which is immutable is stored on a Stack data structure since it’s size is known during compilation phase.

Mutable data types such as Objects, Arrays are stored on a Heap data structure and a reference to the Object or array is stored on the stack data structure.

Currying Step-By-Step

Vasil Vasilev — Mon, 10 Jul 2023 17:06:14 +0000

Definition

Transform a function that takes multiple arguments into a series of functions that take a single argument each.

Reason

The main advantage of currying is that the new function can be partially applied to its arguments.

Instead of:

function sum(x, y, z) { 
    return x + y 
} 
sum(1, 2, 3); //LOGs: 6

We have:

function sum(x) { 
    return (y) => { 
        return (z) => { 
            return x + y + z;
        } 
    } 
} 
sum(1)(2)(3); //LOGs: 6

Although currying can be achieved via other techniques, for example .bind(), this article focuses on utilizing closures.
Closures enables us to allocate each closure for a returned function to a specific variable:

function sum(x) { 
    return (y) => { 
        return (z) => { 
            return x + y + z;
        } 
    } 
} 
const addOne = sum(1)
const addTwo = addOne(2)
console.log(addTwo(3)) //LOGs: 6

1. When execution of the code comes to "const addOne = sum(1)", JS creates a closure for the returned function that captures the value of x as 1 in the Heap memory:

In HEAP: x = 1

In Stack:
(y) => { 
        return (z) => { 
            return x(1) + y + z;
        } 
    }

2. when execution of the code comes to "const addTwo = add(2)", JS creates a closure for the returned function that captures the value of y as 2 in the Heap memory:

In HEAP: x = 1, y = 2

In Stack:
(z) => { 
            return x(1) + y(2) + z;
        }

3. when execution of the code comes to "console.log(addTwo(3))", JS creates a closure for the returned function that captures the value of z as 2 in the Heap memory:

In HEAP: x = 1, y = 2, z = 3;

In Stack:
x(1) + y(2) + z(3);

All that is left is the execution of the final return:

function sum(1) { 
    return (2) => { 
        return (3) => { 
            return 1 + 2 + 3;
        } 
    } 
} 
const addOne = sum(1)
const addTwo = addOne(2)
console.log(addTwo(3)) //LOGs: 6

Why You Should Understand Closures To Master .reduce()

Vasil Vasilev — Mon, 10 Jul 2023 14:30:46 +0000

Although closures are one of the most potent features of Javascript, in my experience, they seem to be neglected in many explanations as if the reader is to infer what is under the hood on their own. If you look at a few articles about .reduce(), they may explain how we define it, the mechanism behind it, but not how it is possible for .reduce() to happen in the first place. This has proved especially irritating for me, in the beginning, since it left a feeling that I have to learn the concept by heart and I had to revisit the basic explanation after some time has passed.

So what is the basic definition?

The reduce() method executes a user-supplied "reducer" callback function on each element of the array, in order, passing in the return value from the calculation on the preceding element. The final result of running the reducer across all elements of the array is a single value.

What would a basic code example look like?

let arr = [1, 2, 3];

const arrSum = arr.reduce(
    (totalOrAccumulator, currentValueToAddToTotalOrAccumulator) => {
        totalOrAccumulator + currentValueToAddToTotalOrAccumulator
    }
)

console.log(arrSum)

The fundamental question is - how does .reduce() keep record of totalOrAccumulator's value during execution?

The answer - closures.

But before that we must take into account another "oddity" with the code above.
.reduce() is a higher-order function since it returns another function (callback fn), that being the one that actually has the parameters and the logic of accumulating the total value.

This is a crucial point because closures provide a way for the callback function to maintain and update the state of the accumulator throughout the reduction process, resulting in the desired outcome.

It is also a process that is hidden when implementing .reduce() and although that is a out of necessity for clean and succinct code, beginners may find it hard to wrap their head around what actually enables .reduce() to keep track of the total value (accumulator).

It is hidden because the initial value is optional but it is the definite mark of closures in .reduce().

initialValue - mark of closures

The following code is an example of reduce used with initialValue and it is a mark of closures, too, for the keen eye.

const array1 = [1, 2, 3, 4];

// 0 + 1 + 2 + 3 + 4
const initialValue = 0;
const sumWithInitial = array1.reduce(
  (accumulator, currentValue) => accumulator + currentValue,
  initialValue
);

console.log(sumWithInitial);

Basic closure example:

function closureFunction () {
    const number = 0;
    function addToNumber(addedNumber) {
        return number + addedNumber;
    }

    return addToNumber
}

const addFive = closureFunction();

console.log(addFive(5));

The code above reveals the fundamental parts of a closure:

a higher-order function that returns another function
a variable that is accessed by the returned function via lexical scoping
explicit return of the returned function
storing of the closure function in a variable

The effect of the four steps above results in the greatest power of closures - we can access the variable stored in the closure function even after its execution. The reason for that is for a whole new article, but simply said, that variable (number in our case) is stored on the heap memory, not stack memory.

Comparing the closure example and the .reduce() example with intialValue, we can clearly see how a variable maintains and updates the state of the accumulator throughout the reduction process.