Forem: Ashwanth A R

Demystifying JavaScript Closures

Ashwanth A R — Sun, 27 Sep 2020 19:15:41 +0000

For a long time, I've perceived closures as this arcane topic that had a tendency to unnerve me. However, it is a powerful feature of JavaScript that lets you do some neat stuff. In this article, I will cover its basics and we will look at one practical usage, and hopefully you will find it intelligible as well (if you don't already).

The core of JavaScript

JavaScript is a single-threaded language. This means that it can only run/execute one piece of code at a time and must finish it, before executing the next bit. In layman's terms, it cannot multi-task. In more technical terms, it has,

One Thread of Execution
One Memory Heap
One Call Stack

The thread of execution basically refers to JavaScript's thread, going line by line over your code and executing each line. There is a caveat to this however. If a function is encountered, JavaScript will declare the function in memory and move to the next line after the function. It will not go into the body of the function until a function call is encountered. Once the function completes, it will then jump back (return) to the line that initially called the function.

Before your code starts to run, a global execution context is created with a memory heap. An execution context is the environment in which your thread of execution runs.

Every time your thread of execution enters an execution context, this context is pushed onto your call stack. Therefore when your code starts to run initially, global context is pushed onto the call stack and the JavaScript compiler encounters LINE 1.

It takes the entire function definition (along with the code) and stores it in the memory heap. It does not run any of the code inside the function.

The next line in the order of execution is LINE 6, where the function is called (or invoked). When a function is called, a new execution context is created and pushed onto the stack. It is at this point, that JavaScript enters inside the function to execute the function body (LINE 2).

It is also interesting to note that LINE 6 has not completed its execution though (result is still uninitialized), it is now waiting for the function to complete its execution at which point the addOne() context is popped off the stack and destroyed. Before destruction however, it will return the calculated value back to LINE 6 and initialize the value of result.

Where do closures come into the picture?

Now, I mentioned in the previous paragraph that the execution context of addOne() is destroyed after the function has completed its execution. So there is no label called "val" in our memory with a value initialized to it anymore. Its all been completely removed from memory.

This behavior is a good thing, because each time we run our function with different arguments, we don't typically need to know what values the function was previously run with or what intermediate values were generated during execution. But, there are some cases where having memory attached to our function definition that persists across execution will prove to be a powerful capability that lets us do incredible things.

Attaching memory to function

Let's look at some code,

function createAddFunction(n) {
    function addByN(val) {
        return val + n;
    }
    return addByN;
}

const addBy10 = createAddFunction(10);
console.log(addBy10(2));

Here we have a function, createAddFunction which takes a parameter n and returns a function called addByN. Let's break this down. When the compiler starts, it creates a global context, and encounters LINE 1 where it defines a label in memory (called createAddFunction) and stores the entire function definition under this label.

Next, it creates a label in memory called addBy10 which remains uninitialized till the function call createAddFunction() finishes execution and returns. When this function gets executed, it creates a new execution context and pushes this on to the stack. Since we pass the value n as 10, this gets stored in the createAddFunction context. In the function body, it also defines addByN function to be stored in memory.

Then it returns this function addByN to be stored as initial value for addBy10 label in memory. Once the value has been returned, the createAddFunction execution context is popped off the call stack and destroyed.

We then invoke the function addBy10(2) with an argument 2.

Our addBy10 function would be defined as above. Its the same as our addByN function except it is now stored under a different label in memory. Here comes the kicker. The parameter val takes on the value 2, but what is the value of n ? Its not defined inside our function, nor is it defined in our global execution context. Furthermore, there are no other execution contexts left because createAddFunction context was destroyed. At this point, we would expect n to be undefined, but its not. Thanks to how JavaScript behaves in these circumstances because of closures. Our function somehow remembers that the value of n at the time of function creation was 10 and thus we can say, our function has persistent memory.

Lexical Scoping and Closures

Scope is the set of rules in a programming language that dictates what data is available to the compiler within a particular execution context. JavaScript has the scope rule of Lexical / Static Scoping. Lexical Scoping is a description of how the JavaScript compiler resolves variables names when you have functions nested. That is, the parent of a function determines what data that function has access to (in addition to the data that is local to the function).

When the thread of execution is inside the inner execution context, it has access to variables defined in the outer execution context via our scoping rule.

So, when the addByN function is returned from the createAddFunction execution context, it takes along with it all the variables that it has access to. Because of lexical scoping, this includes the key-value pair of n and 10. This is called a closure. A closure is the combination of a function and the lexical environment within which that function was declared

So, our label addBy10 is not merely a reference to a function anymore, but a reference to a function and a data store (that persists before, during and after the function call).

It is important to note that this value of n = 10 cannot be accessed in any other way but by calling the function and this usage depends on how the function was originally defined. Hence, it is protected persistent data.

Iterators using closures

A good example for closures is iterators in JavaScript. An iterator is an object which defines a sequence of values that can be accessed by having a next() method which returns an object with two properties: value (next value in the sequence) and done (boolean to track whether sequence has already been iterated over).

If we try to implement a simple iterator, we can see the usage of closures.

const makeIterator = (arr) => {
  let currentIndex = 0;

  return {
    next: () => {
      if (currentIndex < arr.length) {
        return {
          value: arr[currentIndex++],
          done: false,
        };
      }

      return {
        value: arr[currentIndex++],
        done: true,
      };
    },
  };
};

The makeIterator function creates/makes an iterator object and returns it. This can be used as follows:

const iterator = makeIterator([1, 2, 3]);
let result = iterator.next();
while (!result.done) {
  console.log("RESULT", result.value);
  result = iterator.next();
}

We had to use a closure in this case because we needed to store (in memory) and track the currentIndex across the next() function calls as we consume our iterator.

Some other places where closures are used are in the implementation of generators, promises etc. It can also be used in functions that perform large computations to store previous computations in order to not repeat it if the same arguments are passed in (memoization). Closures provide you a powerful toolkit to writing modular optimized code. And I hope with this explanation, you are as excited about using them to write better code as I am.

If you have any feedback, questions, clarifications, please drop a comment and I'm happy to engage in a discussion to improve the quality of my content. Thanks for reading.

How to publish npm packages?

Ashwanth A R — Sat, 07 Sep 2019 09:46:58 +0000

Publishing an npm package, it turns out, is not as difficult as one assumes it to be. This article will walk you through the process I followed when publishing a recent package of mine called react-client-dimensions. I chose to write the article with a very specific example rather than a general mock example since I find such articles more valuable, albeit the scope it covers is limited.

What is the package?

Before I walk through the steps of publishing an npm package, let me first tell you about the package. In several of my hobby projects (mostly react), I need to render a different component based on the window (or client or viewport, whatever you want to call it) size. This makes it easier to handle specific requirements for a responsive layout where media queries are not as straightforward. So I wrote a custom hook that tells me what the client dimensions are, i.e. the width and height. I was using this hook across several projects, so I decided to publish it as an npm package. Now I can use it by just installing a dependancy rather than copy-pasting my code every time.

Initial Setup: Got node? Okay, create directory.

Make sure you have node installed on your machine. A node installation will also give you npm out-of-the-box which is more than sufficient but I prefer to use yarn (which is what this article will use). Take your pick, they are substitutable with each other. You can install node from here and yarn from here.

The first step is to create the project directory you want to publish. In my case, I create a folder called 'react-client-dimensions'.

mkdir react-client-dimensions
cd react-client-dimensions

The all-important package.json

To generate your package.json file, run yarn init command inside your project directory. The CLI wizard will guide you through a series of steps to generate your package.json configuration. Alternatively, you can use yarn init -y which has a flag to quickly set you up with a default configuration.

This is all that we need to publish the package. I prefer to publish the package at this point so that I can change the name if it's not available. I had initially tried the name react-window-size but it was already taken, so I settled for react-client-dimensions. To publish, you need an npm account. In your command line, authorize your login credentials using the command:

npm login

Before publishing, it is a good idea to add a license, changelog, and a readme file. NPM will always automatically include your package.json, readme, changelog and license no matter what.

touch README.md CHANGELOG.md LICENSE

I usually use the MIT license which can be found here. My changelog file is typically in the following pattern.

To publish our package to the registry run,

npm publish

Writing the source code

Now we write the actual package. The meat and potatoes of what we want to achieve with the package. Typically source code is written in a directory called src which separates it from the rest of our codebase. This also makes it easier to bundle all your code into a lib or dist folder after you've pre-processed your code for production use using tools such as Babel or Webpack.

There we have it. Our source code for the package. We're almost ready to publish it but not quite yet.

Transpiling our code with Babel

The code we have written uses ES6+ syntax which is not supported in older browser versions. For example, arrow functions is an ES6 feature and you can see the status of support here. In order to make our code work across all environments, we use a compiler (called Babel) to compile our code and package it.

We install the dependencies (as dev dependencies) for Babel using the following command. These are dev dependencies because our packaged code does not depend on.

yarn add -D @babel/cli @babel/core @babel/preset-env

Babel is a JavaScript compiler that converts ES6+ code into a backward-compatible version of JavaScript in old browsers or environments. The Babel CLI (@babel/cli) is a command-line tool that provides your command line with the ability to run the babel-core API (@babel/core) on your source code.

With just these tools you will find that there is a lot more work that you need to do in order to micromanage the syntax transforms that are needed by your target environment. To simplify this, we add a preset (@babel/preset-env) which does this work for you in a concise manner.

Now we need to tell our babel configuration to use the preset-env that we installed. We can do this by adding our babel config to our package.json file. We edit our package.json file to look something like this.

The important changes you need to note here are:

Update main entry point to "lib/index.js" because that is where we ask babel to store our production-ready source code.
We added our @babel/preset-env preset to our babel config.
We added a "build" script which uses Babel CLI to transpile our code and put it inside the lib folder. You can run it using the command: yarn build.
Every time we publish we need to run the build command first. We can automate this step by adding a "prepare" script which npm automatically runs when you run: npm publish
We want npm to only publish our lib folder. So we include it in the files attribute.

In this case, we tell npm to publish our package only with certain files and folders (whitelist). Alternatively, you can choose to tell npm to avoid certain files and folders (blacklist) using the .npmignore file. However, I find blacklisting a more troublesome option than whitelisting. You can read more about these options here and here.

Semantic Versioning

The source code we added is a new version for our package. NPM won't let you publish this version without updating the version attribute of your 1package.json` file. To do this, we follow a versioning system called Semantic Versioning. You can read more about this here.

We want to patch update our version. So we run npm version patch to update our version.

npm version patch -m "Added source code for useClientDimensions() hook"

Once our versioning is done, we are ready to publish our package. Simply run npm publish and you are done. Your package is out there now. :)

Check out my package react-client-dimensions here. Tell people about it if you find it useful.

Thanks for reading. Drop me a comment if you have feedback/suggestions. I highly appreciate those.

Have a good day.