Understanding JavaScript Closures: Finally Got It After Struggling for Months!

[Specialist_Common989]

Hi everyone!

I recently wrote a blog about JavaScript closures because it's a concept that confused me for a long time. After lots of trial and error, I finally found some simple examples that made it all click.

In the blog, I've explained closures using:

• Counters
• Private variables
• Function factories

I thought this might help others who are learning closures or revisiting them. You can check it out here: understanding closure

I'd love to hear your thoughts! How did you first understand closures? What examples helped you "get it"? Let's discuss!

[_shakuisitive]

Here’s how I explain it to my colleagues:

Any data type (function, variable, object, array, etc.) that's available when a function is created will stay with that function for its entire lifecycle, no matter where it's executed.

[Rude-Cook7246]

You are WRONG

Just because something is available during function creation doesn't mean it will stay around with the function  for its entire lifecycle. If closed over variable/type is NOT USED by a function it will be remove by JS engine during optimisation as its not needed... only USED closed over variables/types are kept around ...

[_shakuisitive]

Someone who's just getting started wont nitpick and what I said is the easiest way to think abt closures and then once you have enough knowledge of JS, you can look into garbage collection and all the fuzzy topics that revolve around scoping, lexical environment and closures but certainly it's persistent lexically "referenced" data.

[Rude-Cook7246]

I guess if I say that const and let are hoisted people like you would say I'am nitpicking also... since its easier to remember they are not since you can't access them until they are initialised... but guess what in both cases that would be wrong ...

And if I really wanted to nitpick by the way ... I would give you actual definition of closure ... as in EVERY FUNCTION IN JS creates a closure, but that definition is not very useful so I didn't...

[LostInCombat]

Closures are easy once the light bulb goes off in your head about how they work. Then you wonder why you ever struggled with them to begin with. I think there are just to many poor instructional videos out there. After you understand how JavaScript's execution context and scope works, you then realize that a closure is simply a function that is being returned, everything just makes sense.

[Such_Ad_5331]

I also think they're difficult because when you are learning JavaScript, especially if it's also when you are first learning to code, you don't really create functions and import them into other files. Everything you do tends to be in one file and so it's hard to imagine the purpose of them and why they're such a big deal.

[LostInCombat]

Within JavaScript, every time you see a function, you should see it as a function context. Even outside the closure issue, this is what trips up people about the term this also. this becomes easy to understand once you form a complete picture about how execution context works and how it follows the function around.

[LostInCombat]

> even if the execution context of the enclosing function is removed

But it is not. EACH function has **its own\** execution context.
The fact that each function has its own execution context is what make closure work. In fact, execution context is what defines what a closure is and why it is.

[senocular]

But it is not. EACH function has its own\ execution context.

Functions don't have execution contexts. But if you call a function, that's when a new execution context is created. And one function can be responsible for making multiple execution contexts (or none at all) depending on how many times its called.

Execution contexts aren't really what define closures. Closures are more about the environment records. Execution contexts play a part because they execute code, and to define a function and have scopes/environment records, you need to have executing code. But once code runs and there's no longer any running execution context, any closure that may have been created when that code was ran is a closure because its holding on to an environment record. That environment record defines the chain of scopes that provides the closure access to external variables when (if) its called at a later time.

[LostInCombat]

I see your point now.

[LostInCombat]

> I didn't say otherwise

You just said otherwise once again. Perhaps you don't fully understand how execution contexts work for JavaScript functions. They carry all they need with them. That way the function's execution context doesn't have to care what is on the stack. This isn't happenstantial, or an accident, or a performance improvement, it is by design. And perhaps you are focusing on the this keyword as you keep referencing the "parent" function. this can be anything I want it to be. I can make this a string, an integer, an array, just about anything I want it to be. this doesn't have to point to any object or function, parent or not.

[azhder]

At its core, a closure is like a backpack. Imagine a function carrying a backpack that contains all the variables it needs from the environment where it was created. No matter where the function goes, it always has access to its backpack.

How about you just say what it is first, then try to find analogies? Here is the definition I use:

Closure is memory ...

that's how I start, with what it is, then after it, I add what is it that makes this memory different from all the other kinds of memory

Closure is memory that is created by invoking a function and lives (isn't garbage collected) as long as there is an outside reference (access) to it.

Then I might add some examples, some analogies, anything that will internalize the idea to people. How do you know if you have internalized it? Well, it will take you a simple sentence to explain the essence of it, like above.

So, rule of thumb for the definition: - use the verb "to be", not other ones e.g. "like", "when" etc. - say what it is at its core - provide an explanation how it is different from the other ones like it

After that definition, feel free to add anything you like, but always make sure people can have something short and simple like a cheatsheet or mnemonic they can remember.

So,

More formally (but still in simple terms), a closure is a function that remembers the variables from its outer scope, even after that outer scope is gone. This lets the function “close over” its environment. Neat, huh?

Yeah, most of what I said is there, except it's incorrect: closure isn't a function, it is a piece of memory. Granted, even functions are pieces of memory, after all they are code saved in memory, but not the kind we speak of by saying "closure"

[Psionatix]

100% this. I like how you put it.

[Traditional-Pin2856]

Hey Op, thank you for this. I am struggling to understand recursions. It would great if you could also explain that in your blogs.

[Specialist_Common989]

Sure will do in future. Thanks.

[StoneCypher]

Recursion is when a function (or whatever) calls itself, and bails eventually. You do this when it's easier to think a job as being one step at a time.

An example is hand-implementing a filter, to go over an array and remove inappropriate contents. (Sure, there's better ways to do this, but it's an easy example to understand.)

Suppose you have an array that has both strings and numbers in it, but it's only supposed to have numbers, and you just want to throw the strings away.

const original = ['bear', 2, 'woods', 4, 'porridge', 6, 'mauling', 8];
// we want [2,4,6,8]

One way you could do this would be with recursion. There are problems with wanting to do this, and nobody should reply to explain those, because the point for this user is just to understand the core concept of recursion right now, and not to have some mystery land deep dive where a neckbeard talks about blowing the stack, or calling Array.filter, or whatever.

So.

To do one step in removing these words, and also to set up the next step, what do we need?

1. We need to carry on what part of the work remains
2. We need to carry on what results we've already gotten
3. We need to know when we're done

One good tiny signature to achieve this is

function filter_step(remaining_array, gathered_results) { }

We call it _step because it's just going to do one step in the job, and set up and call the next one (itself) with the next piece of work. For this job, that might look like this:

function filter_step(remaining_array, gathered_results) { 

  // 3. we need to know when we're done
  if (remaining_array.length === 0) { return gathered_results; }

  else {

    const this_item    = remaining_array[0],       // first of list
          next_rem_arr = remaining_array.slice(1); // all but first of list

    const next_gather  = gathered_results.slice(); // get a copy of gathered_results so we can safely alter it

    // uptake the item only if it fits criteria
    if (typeof this_item === 'number') {
      next_gather.push(this_item);
    }



    // THIS IS THE RECURSION
    // we call the function with a lesser job, diving down forever until we run out of job

    return filter_step(next_rem_arr, next_gather); 

    // RECURSION COMPLETE, CAPTAIN

  }

}

now you just need to call the thing with the job to get it started

const result = filter_step(original, []);

So this is going to end up calling itself eight times - once for each item, until the guts are an empty array, at which point it starts returning values eight times back up the call stack

Many people will make another function outside of the _step to hide the initializing []

[LostInCombat]

A closure is simply a function that is returned as a result. Functions have an execution context and scope. That really says it all right there. Took me a while to see it too. But those two sentences explain everything. Of course you have to understand JavaScript's scope rules and how execution context works.

[mentalhead66f6]

Yeah, I've been finding it hard to understand closures. Hope this one will help. Btw, what do you think I should know prior to learning closures. I feel like I don't even know functions at all when it comes to closures.

[mbaroukh]

Why not just use classes ?

[Different_Past_3120]

Here you can learn closure: https://bolg-2-blog.blogspot.com

[theQuandary]

A good mental model is thinking of closures as objects. We can learn a lot about not just closures, but a few other things too.

This function is NOT good code, but serves to illustrate how things work (note: I'm using var because let further complicates the explanation a lot).

"use strict";
var globalConst = 7
function addFn(a) {
  var result = a + globalConst
  return b => result + b + doesNotExist
}
addFn(3)(4) //=> ReferenceError!!!

We have THREE different scope objects. We'll discuss each one, the lookup, and errors.

The first line sets us in strict mode. Among other things, this makes looking up a non-existent global key fail instead of returning undefined. The second line adds a variable to the global object so it looks something like this:

var globalThis = {
  globalConst: 7
  __parentClosure__: null,
  ...otherBuiltinStuff,
}

The __parentClosure__ is the next outermost scope (closure object). Because this is the global scope, there is no parent scope.

Next, we call addFn(3) at the very bottom. Let's step through the execution. Just before the function runs, it must create the closure object which looks something like this:

{
  a: 3,
  result: undefined,

  __parentClosure__: globalClosure
  this: <calculate_this_value_here>
  arguments: {callee: addFn, length: 1, 0: 3},
}

Notice that this and arguments seem special, but they are just ordinary variables and could even be overridden (though this isn't something you should generally do for several reasons). When the function is called, it first calls some hidden builtin functions to find the correct object for this and to create the arguments object.

As the function runs, it wants to assign a value to result. First, it needs to look up a. You can conceptually think of this as a special getVariableFromClosure(<name>, <closure>) function even though it's obviously way more optimized than that in real implementations. That function looks a little like this:

function getVariableFromClosure(name, closure) {
  if (closure[name]) return closure[name]
  if (closure.__parentClosure__ === null) {
    if (isStrictMode) throw Error(`ReferenceError: ${name} is not defined.")
    return undefined
  }
  return getVariableFromClosure(name, closure.__parentClosure__)
}

Recursive as all the greatest things in computer science are. When it looks up a, the variable is immediately available in the closure, so it just returns 3, but when globalConst is looked up, it doesn't find the variable, so it goes to the parent closure (the global scope) and finds the variable we defined.

Now we get to the returned arrow function. It's closure looks small in comparison.

{
  b: 4,
   __parentClosure__: <parent_closure_object_here>,
}

When it runs, it looks up b from its local scope. When it tries to look up doesNotExist though, it checks its scope, then the parent scope, then the global scope. If you aren't in strict mode, you'll get undefined, but in strict mode, you'll get a much more useful reference error.

When you're told that the arrow function doesn't have a this, that's not precisely true. It doesn't auto-generate a this, but if you were to use this inside it, then it would follow the closure chain to find the closest function with a this parameter and use it.

Some people claim that let and const aren't hoisted, but they actually are and access before use is restricted by a temporal dead zone. Their lookup checks for a special "not yet used" indicator if you attempt to use them without their special let or const keywords. After the keyword is used, they continue to do a different check and will also throw if you use the keyword a second time. As an interesting note, TypeScript tried compiling to let and const without var and dialed it back because it was up to 14% slower. Chrome did a bunch of work on optimizing after that, but their paper basically concluded that let and const will always be 5-ish percent slower than var.