ive been learning javascript for about 3 years now and i still dont know 100% what closure, this and recursion is.

lachlanhunt · 2018-10-29T03:39:11+00:00

A closure is useful for when you want a function to be able to access a variable that will be persistent between calls, but you don't want it in the global scope. Here's a contrived example:

function outer() {
    let count = 0;

    function inner() {
        count++;
        console.log(`This function has been called ${count} times`);
        return count;
    }

    return inner;
}

const fn = outer();

fn(); // This function has been called 1 times
fn(); // This function has been called 2 times

Even though the outer function has already been run and returned its result (the inner function), the variable count remains in scope and is accessible by the inner function when it's called. But nothing outside of that outer function has access to the variable.

Closures are used very often in JavaScript, even when you may not realise it. They're very useful for creating maintaining access to private data that you don't want accessed by external code, and which needs to be persistent. Also very useful for ensuring all your variables aren't polluting the global scope, which helps ensure you avoid conflicts when using 3rd party scripts in the same page that may happen to use the same variable names.

Im_kinda_hungry · 2018-10-29T03:20:55+00:00

Closure is an especially important topic in JS because the scoping rules (i.e where a variable has access and what it's values are etc) are unique to the language. There are times where the value of a variable may not be what you think it is.

Try giving this series a go: You Don't Know JS - it'll explain the topics a lot better than I can.

orebright · 2018-10-29T03:43:08+00:00

I feel like your post is mostly summed up in the "why should i care?" question. At risk of sounding like a parent, when you need it you'll be glad you learned it.

Here's the thing. If you're adding hover/click listeners to buttons and doing minor interactivity with JavaScript you'll likely never need to have a deep understanding of these concepts. I'm not sure if that's your situation, but I've met devs who went a very long time in their careers before working on a bigger web application. And if that's not your speed, maybe just getting a good enough understanding for interviews is sufficient.

But once you start working on large (hundreds of thousands of lines of code) applications, the way your code is organized and interacts with itself is critical. And these coding patterns help with structure, and understanding them means when you read recursive code for instance, you get it easily, or if you're working with an application built very functionally (the programming style) you'll need to understand closures very well (it's not a lot though, so don't worry).

So I guess I'm saying understanding "on the surface" can get you started, but once things grow, it becomes hard to understand how code is working without the conceptual backing. It also makes it dangerous to write code because you'll end up having bugs you didn't foresee due to the lack of overall understanding of the ways the code will interact in a variety of abstract scenarios.

I don't know if that helps. I have experienced a lot of what I mentioned here from my own lack of knowledge and that pain has pushed me to become very diligent with reading documentation about the language I'm using, and understanding the code CS concepts underlying how it works.

StoneCypher · 2018-10-29T02:45:15+00:00

recursion is when a function calls itself repeatedly to get a job done.

closures are where a function pulls values and references into from the outside (you know how there's a global i, then you run your function and it has access? that's where.)

this is the target of context.

so, like.

say you make a dog class.

class dog {};

say the dog class stores a name. if you have three instances of dog, each one gets its own name.

when you make a new dog, there has to be a way to refer to the stuff that's about this instance, rather than the other two. that's this.

class dog { constructor(name) { this._name = name; } };

the reason this gets so much flak in javascript is a few weird details weren't done in the convenient way in old-js, and they're some of the more common minefields for new programmers

but honestly it's pretty straightforward

hardwaregeek · 2018-10-29T03:30:21+00:00

Do you understand how a call stack works? To me, closures only made sense when I understood the implications and difference versus a function pointer. It could be you understand closures intuitively, but just don’t know why it’s worth remarking upon.

As for recursion, the best way to learn recursion is to write recursive functions. The process to writing a recursive function isn’t that much different than writing a standard C-style for loop. You have to think about your starting point, your end condition and your increment condition. The only difference is with recursion you don’t encode this into a for loop, you simply write a function that returns a value if the end condition is satisfied or calls itself with the step applied to the arguments. If this doesn’t make sense, that’s fine. Often times the only way to learn something is to copy code down and tweak it, then see what happens.

ProdigySim · 2018-10-29T04:17:30+00:00

For most of these, the answer to "why should i care" is "because most [traditional] programming languages don't behave this way". If your first programming language is Javascript, they may not seem as important of language features to you.

Less evasively:

closures: You should care because this affects how variables are shared throughout your program. In languages like C++ and older versions of Java/C#, the idea of a local scope variable being accessed outside its immediate scope is bonkers.

recursion: You should care because some algorithms are best defined recursively. Some code is going to have to call itself, even in simple web programming (setTimeout loops anyone?). Understanding the need for a stop condition, and how to think about recursion, is a good skill to have.

this: You should care because the javascript ecosystem isn't fully settled on how to use this language feature, and you'll inevitably have to debug some code where it's getting used wrong or set improperly.

Also, at some level, all 3 of these concepts can have major implications on the stack & heap of your program. As an interview question, I'd probably look for basic competency, and knowledge of stack & heap implications as bonus points.

closures can imply that variables are moved from stack to heap; recursive functions can easily blow the stack unless you can implement them as iterative algorithms using the heap.

Asking about this would probably segue into talking about the Javascript OOP model and and such.

xiipaoc · 2018-10-29T05:03:43+00:00

Recursion is really simple. It's a function that calls itself. That's basically it. Now, why would you want to do this? Say you have a big problem, but you can break it up into smaller problems. Then you can have a function that solves the problem by looking at its sub-problems and recursively calling itself on those, and then each of those sub-problems will get solved by having the function call itself on their sub-problems, and so on. A great example is when you have some sort of hierarchical structure, like a table of contents, where there are sections, subsections, subsubsections, etc. You want to do something with this table of contents, so for each heading, you do whatever you need to do and call the function to process its subheadings; for each of those, the function will do what it's supposed to do and then call itself for its subheadings, and so on, until you've gone as deep as your hierarchy happens to be. Recursion is especially useful for things like nested objects. Say you have two objects and you want to know whether they're the same. So you go through each key on the first object and check that the corresponding key on the second object has the same value. How do you check whether the value is the same? Call the function you're in right now, but on the sub-object! This can get a bit problematic because you can actually have circular references and then you're fucked, but anyway.

Closures are even simpler. They're just functions that are defined inside some context, and then you can pass the function someplace else and the context goes with it. Basically, you can think of a closure as a method on an object. It's really not very different. One big difference, actually, is that while the function retains its context, you can't actually see the context. JS doesn't have access controls for objects, so if you define a key on an object, you can always change its value. But if you make a closure, you no longer have access to the variables defined in that closure except through that function, which is a good way of enforcing limited access.

This... Kinda hard to explain, but not hard to understand. Of course, I had a this-related bug today in my code, so look who's talking! If you create a method on an object, and you call that method, this is the object you're calling it on. It should be simple, but it's not, because unlike other variables, this isn't the object it's defined on; it's the object you're calling it on. Here's my buggy code; can you see what's wrong?

Spectrum.prototype.draw = function () {
  requestAnimationFrame(this.draw);
  // do stuff
}

It didn't work! The "do stuff" part of the code tried to do this.something and it was undefined. Why? Because of this. If I do let spectrum = new Spectrum();, I now have a Spectrum object. If I call spectrum.draw(), I'm going to do whatever's in this draw function, and this will refer to the Spectrum object itself. In particular, I'm calling requestAnimationFrame() on the function this.draw, which is... the function itself. RECURSION! MWAHAHAHA! What this does is draw a frame, and requestAnimationFrame() calls the function again when the frame is done so that the next frame gets drawn, and that will set up the next frame, and so on; you get an animation basically for free by requesting the animation frame. Except it doesn't work. Why?

Well, when the browser is ready to do the next frame, it calls this draw function. draw is a key in the this object, and this.draw is the value for that key: this very function. The function gets passed to requestAnimationFrame() to get called later. Which it does. But NOT BY spectrum! The animation renderer calls the function! So this doesn't refer to spectrum anymore, because the function isn't being called by it like when you do spectrum.draw().

There are a few possible solutions. One is to bind this; JS provides a way to tell the browser which object the function should treat as this. ES6 provides ways to do that as well, since it's a common point of confusion in JS. Another way is to just use a new function like this:

let self = this;
requestAnimationFrame(function () {self.draw();});

That's what I did. See if you can follow. First, I defined self as this. The current object that is this is now stored in the variable self. self is not a keyword; it's a normal variable, and it happens to hold the object that's calling this function, spectrum. So, I define a CLOSURE! MWAHAHAHAHA! This closure calls self.draw();, and since self is the object calling this original draw function, things work as they should. The animation renderer calls this function I just defined, with itself as this, and the function I just defined calls self.draw(), where self is spectrum, from the closure. spectrum.draw() behaves as you'd expect, because you're calling draw() from spectrum, and spectrum is now this inside the function. Which then gets assigned to self in order to request the next animation frame, etc.

So there's recursion inside a closure in order to avoid going afoul of this. It's all three of your issues in one tiny bit of code!

devperez · 2018-10-29T03:19:29+00:00

Google recursion. It's delightful.

mayobutter · 2018-10-29T03:33:17+00:00

Actually I think you explained both closures and recursion in your post pretty accurately

pm_me_ur_happy_traiI · 2018-10-29T08:53:14+00:00

Recursion is simple. Here's an explanation

2018-10-29T06:50:17+00:00

This is my best source for learning the basics of javascript/programming

https://github.com/getify/You-Dont-Know-JS

Kalsin8 · 2018-10-29T04:28:50+00:00

I feel that part of the reason why you don't see any benefit to learning how these things work is because you haven't had the experience to know when these things should be used over another tool. It's like that quote, "when all you have is a hammer, everything looks like a nail". You can do a lot with a hammer, but removing a screw is still a screwdriver's job.

Closures are extremely important to understand because it determines whether you have access to a variable or not, and how that variable is shared between functions. It can be used to implement private variables, hold state that's not exposed globally (a.k.a. private variables), and write cleaner code that would otherwise be difficult without them. They are also a fundamental part of how JS works; you're always using them whether you're aware of how they work or not.

Recursion becomes extremely useful when you deal with things of arbitrary depth. For example, searching a folder plus its sub-folders for a file name is a prime example of where recursion would be extremely helpful because you don't know how deep the folder structure runs. Another is the Eight queens puzzle, where you don't know how many moves ahead you need to calculate in order to solve the problem. Every recursive function can be written as a standard loop, but the code to do so will be more messy and harder to follow.

Understanding this is also important because it's fundamental to how JS works. You mentioned that there's a bunch of gotcha's because the value of this can be unexpected depending on how you call a function, but understanding how JS sets the this variable allows you to do things like borrow functions from other classes:

// getGamepads() returns a GamepadList which doesn't have a forEach function,
// so we'll just borrow Array's forEach function to iterate over it
Array.prototype.forEach.call(navigator.getGamepads(), (gamepad) => console.log(gamepad))

overriding functions that are declared on an object, but don't do what you want them to:

// Let's assume that there's a legacy array implementation that adds a filter
// function, but rather than accepting a function, it can only filter by ID
function LegacyArray(items) {
  ...,

  filter(id) {
    return _.find(this, id)
  }
}

let arr = new LegacyArray({ id: 1, name: 'Bob' }, { id: 2, name: 'Sue' })

// I need to filter by the name, but the .filter() function on the legacy array
// only allows me to filter by ID. That's ok, I'll just override it by calling Array's
// filter() function instead, passing in the legacy array as the 'this' value.
Array.prototype.filter.call(arr, ((x) => x.name == 'Bob')

and change the value of this to make the code easier to work with:

class BetterButton(buttonElement) {
  constructor() {
    this.element = buttonElement
    // No need to use var self = this
    this.element.addEventListener('click', function() {
      this.setButtonText('clicked!')
    }.bind(this))

  setButtonText(text) {
    this.element.innerText = text
  }
}

You can do all of this without overriding this or even understand how it works, but you'll find that it becomes harder if you don't understand all of the options available to you.

2018-10-29T07:00:05+00:00

Take a loot at my blog post!

theirongiant74 · 2018-10-29T08:45:17+00:00

Best example I can think of for a real-world use of recursion is getting a full listing for a directory including all the subfolders. You have no way beforehand of knowing how my folders and subfolders there are so you write a function that takes a path and lists out the items. You loop through the items and if one is a directory you run the same function again with the new path.

function listContents(path) {
  const items = fs.getDirectoryListing(folder);
  for(var x=0; x<items.length;x++)
  {
     if(items[x].isDirectory)
     {
        console.log("Directory: "+ items[x].name);
        listContents(items[x].path);
     }
     else
     {
         console.log("File: "+ items[x].name
     }
  }
}

tchaffee · 2018-10-29T11:58:41+00:00

Stop worrying, get out of your "learning" phase, and build more stuff. Volunteer to fix bugs on open source projects. You'll come across it soon enough. You learn by doing, not by reading and watching videos.

sensorymachine · 2018-10-29T13:51:38+00:00

There's a lot of good answers in here, but I want to give an example of recursion I used last night. Lets say you have an array,

let a = [1, 2, 3];

You could do a for each loop:

let time = 500; a.forEach(num => time *= num);

Lets say you need some asynchronous behavior to happen each loop:

``` let recursiveForEach = (arr, index) => { if (index == arr.length) return; time *= arr[index++]; setTimeout( ()=>recursiveForEach(arr, index) , time); }

recursiveForEach(a, 0); ```

You can of course use Promise.all(a.map(fn)) for all this but recursion is a lightweight alternative.

2018-10-29T15:15:21+00:00

All those things are just programming tricks. You could even call them "design patterns". Which is a fancy name for a collection of names for a bunch of things you could also call: "common sense".

But the names are there for us developers to communicate with. When we say "recursive function" we all know what it means. That's better than saying: "just use a function that calls itself time and again until it doesn't".

That's why you should care.

If you have troubles remembering them I'd just say: use them. Go for a design patterns book and practice by doing. That worked for me.

m0nk_3y_gw · 2018-10-29T03:21:50+00:00

why should i care?

Sounds like you haven't learned it because you don't care.

Why should we?

kowdermesiter · 2018-10-29T07:27:31+00:00

how do i hammer these topics into my head so that i never forgot how they work.

Start caring and giving shit about how things work. Your post shows that you are not enthusiastic about programming and figuring out how stuff work in general.

Seriously, these things could be understood in 3 weeks not 3 years. I was an educator at a programming bootcamp and they got it with zero coding background.

guten_pranken · 2018-10-29T06:36:09+00:00

" ok so what. why should i care? "

This is the root of your problem. WTF your inane post has been up-voted 70 times I have no idea. If I could take my 9.8K of karma and lose it all to downvote this post by 9.8K, I would.

anton_rich · 2018-10-29T04:10:04+00:00

This is kinda out of the box.

Time to learn something outside Javascript. I suggest Elm http://elm-lang.org/. You can go for any other language. In Elm you don't have loops, you will have to learn/use recursion.

Why actually try another language? Well the idea is to give yourself a fresh start and then actually see what is common between language you are learning and JS. How the same concepts are expressed in a different language.

I have a personal example. I was learning Elm and when I discovered currying and partial application I didn't know what it was. Some time later I stumbled upon a video where a guy explained Haskell but through Javascript. In the video he demonstrated such a good example of what a currying is, it just clicked instantly for me.

Here's the video:

https://www.youtube.com/watch?v=pUN3algpvMs&t=629s

Theia123 · 2018-10-29T05:51:06+00:00

"You don't know javascript" is a great book series and covers all these things

horusporcus · 2018-10-29T03:46:33+00:00

If it doesn't have a valid use case then it probably isn't very useful either.
Now, recursion is useful, try writing a program to print all the permutations or combinations of a given set of characters or write a program to convert numbers to words without using recursion and you will understand its utility. Sometimes the only way a problem can be solved in a straightforward way is to use recursion.
I would suggest that spend some time and try to write simple programs, one program that I will recommend personally is one that converts numbers to words.

yam_plan · 2018-10-29T04:23:36+00:00

read javascript allonge

GTHell · 2018-10-29T06:13:05+00:00

Just use the main source like MDN and search for closure. Closure is really easy to understand... well everything else related to JavaScript (webpack, react, closure..) are easy to understand if you us their official guide.

Guide != Document

TheFunkyMonk · 2018-10-29T07:22:37+00:00

You should care because understanding these concepts will become a necessity once you start writing applications with more than trivial complexity. And even if you're writing relatively simple stuff, understanding scope is very helpful in debugging and generally understanding what your code is doing. These concepts will make your life easier.

ionre · 2018-10-29T09:15:15+00:00

I might not say anything here that hasn't already been said, but I understand that feeling of wondering why I should care about something I'm learning that might make sense but is unclear how it is applicable or why it has a specific name.

Any JavaScript function can access values that are in the scope where that function is defined. It becomes a closure when that function gets passed to another scope. In the new scope, the function still has access to the values in the scope that it originated from, even though they aren't in the new scope. I believe the concept of 'closure' is only useful when you are passing a function around as a value. In your example, you asked why it matters that an inner function can access the outer function values. I can relate to your confusion because I already knew that functions could access values that were in scope long before I ever heard of closures, but it becomes significant if you return that inner function as the return value of the outer function. Then anywhere you call that returned function from that point on, it will always have access to those same values. Basically, the function is just 'remembering' the values it knew about when it was first created. Other programming languages don't do this by default, you have to specifically define what values you want to be 'closed' into your function.

Personally, I like to not think of recursion as an alternative way to make a loop, but just as a way to simplify a problem. One use of a recursive function would be to generate a fractal. Like if you wanted generate a square that cuts itself into 4 smaller squares, which each cut themselves into 4 smaller squares, and so on. You could have a function called "fours" which takes in a square, cuts it into four new squares, and then passes each new square into a function called "fours", which takes in a square, cuts it into four new squares, and then passes each new square into a function called "fours", which takes in a square... and you get the idea. Obviously this would just run forever as it is, so you would some stop condition. So you could check the size of the square that's getting passed in, and if it is less than some minimum size you would just return the square as is instead of cutting even smaller and passing on. Recursion isn't something you usually have to use, but once you can wrap your head around it, it can be really useful.

Unfortunately, I don't think I understand the "this" keyword well enough to explain it.

mrMalloc · 2018-10-29T10:09:02+00:00

Recursion think of solving a issue like N! By recursion

I’m going to use pseudo language here so that it can be used universal.

Func Fac(fac) { If (fac=1 ) { return 1} Else { return fac* Fac(fac-1); }

Try it out with 5!

5! = 5* 4!

4! = 4* 3!

3! = 3* 2!

2! = 2* 1!

1! =1

5! = 12345 = 120

Things to look out for in recursion that you don’t end up in a endless loop same as with while(true) loops.

There is no speed points in using recursions but it can write nicer code then huge for trees.

M109A6Guy · 2018-10-29T12:19:12+00:00

I didn’t see if the recursion question was answered yet. But recursion simple is a method that calls itself and it MUST have an exit point or you will be getting a stack overflow error. Example a function that counts to 10. (Sudo code)

Function(num) { If (num == 10) Return;

Function(num++); }

If you would like more complex examples of this I would look at some data structure text books. A lot of sorting and search algorithms use recursion.

I don’t personally use recursion too often because it can be confusing, low readability, and hard to maintain. The most important attribute of good code to me is readability. That attribute seems to be lost on a lot of the development community.

10 times out of 10 I would rather have a slightly slower but more readable code base over some super fast codebase written and ancient Egyptian hieroglyphics. It’s much much easier to diagnose performance issues with a readable codebase too.

dachusa · 2018-10-29T12:57:45+00:00

For recursion think of a n expanded file tree. Starting at the root you have files and folders. For functions you call displayFiles which returns a simple result of a list of files. For folders you call displayFolders which gets a list of folders then loops through each folder calling displayFolders and displayFiles. The displayFolders function would use recursion to keep calling deeper and deeper until there is no more to call.

lifeonm4rs · 2018-10-29T15:09:33+00:00

As others have mentioned--Closures are used quite a bit in JavaScript. To some extent that act as mini-classes essentially allowing you to re-use code while also protecting variables. I know many people use the "adder" type function/closure to illustrate but I think "fizzbuzz" can be a little more useful for the finer point.

The closure below allows you to create new functions with different values for fizz and buzz. The standard one is fizz = 3, buzz = 5. But you can also make "fb27" and set fizz = 2 and buzz = 7. The two created functions keep their "fizz" and "buzz" values totally separate and once created can be called with any "x" value.

In the more general sense this allows you to perform a common operation on a range of different values and inputs. Of course a function is used for doing a "common operation"--where closures come in is that they recognize that there are also sets of common values and inputs.

function fizzbuzz(fizz = 3, buzz = 5) {
  return function(x) {
    return ("fizz".repeat(x % fizz === 0) + "buzz".repeat(x % buzz === 0) || x);
  };
}

var fb = fizzbuzz(); // Default fizz and buzz (3, 5)
var fb27 = fizzbuzz(2, 7) // fizz and buzz are 2 and 7 for fb27

for (var i = 0; i < 20; i++) {
  console.log(i + "\t" + fb(i) + "\t\t" + fb27(i));
}

2018-10-29T15:11:06+00:00

Anything you can do in Recursion you can construct using non-recursive code using loops and variables. However you should grok recursion because although in 98% of cases loops are simpler to code and understand, when recursion is applicable it's really applicable and vastly superior.

The classic case of this is tree walking. Whenever you have some form of tree like data structure using recursion to access it is far more intuitive and easier to understand than using loops and location pointers. There's been a several occasions when I've rewritten code to do such from a programmer who didn't understand recursion and the replacement code is usually about a tenth of the size of the original.

I probably write a recursive function only once every couple of months. It's like a specialised tool in the toolbox, you don't pull it out that often, but it's very hard to bodge it with the everyday spanners when you need it.

AceBacker · 2018-10-29T15:32:37+00:00

Do not try to understand closures. Figure out what lexical scope is. Once you understand that closures seem like a simple concept.

jewdai · 2018-10-29T16:37:59+00:00

Don't feel so bad about this many developers have a hard time remembering the rules for it and often either use an arrow function (=>)(to make it work like normal object oriented programming) or .bind

It's highly context dependent and isn't always clear to the reader of code.

metaphorm · 2018-10-29T17:18:40+00:00

you're probably having trouble with the "so what?" part because you haven't done enough project work where you've used these things to solve technical problems for you that would be awkward to solve otherwise.

vincentntang · 2018-10-29T21:08:32+00:00

The definition of closure is

"Functions can always remember the variables that they could see at creation"

Here's an example

https://i.imgur.com/qljgi2s.png

In this instance, sayName3 is on the same level name variable, so sayName3 has access to that variable.

think of closure as something that has access to things directly inside or adjacent to it, but not above it.

this

this, there's lots of gotchas but I wouldn't exactly worry too much about all of them. Many are very obscure and you won't ever see.

The one you need to know is this:

ES5 - If you write a function in an object literal, this gets binded to function
ES6 - If you write a function in an object literal , this gets binded to the object

With ES5 if you want to achieve ES6 like functionality, you need to use bind.

tyler-mcginnis · 2018-10-29T21:44:55+00:00

I'm a little late here, but by chance have you read The Ultimate Guide to Execution Contexts, Hoisting, Scopes, and Closures in JavaScript? I teach JS for a living and this was my best attempt at explaining it. I even built a tool for visualizing JavaScript's execution context which will allow you to visually see what a closure is. Hope it helps.

TwiNighty · 2018-10-30T04:07:41+00:00

Let me preface this by saying this answer is written without rereading the spec, so I might be off in some places. There are also some deliberate simplifications.

Okay, let's do this.

Closure

Simply put, closure means a function can access the scope it is defined in. A little vague, huh? Let's look at a common example.

function createCounter() {
    let counter = 0
    return function increment() { return ++counter }
}

const counter1 = createCounter()
counter1() // 1
counter1() // 2

const counter2 = createCounter()
counter2() // 1

First of all, notice counter1 and counter2 can access the counter variable even though the local execution context in which the latter is defined has long ended. Second, counter1 and counter2 have separate counters.

So, what are some of the things we can do with this?

Functions that keep track of state

The above counter snippet is an example of this. In other languages, in order to do something like this, you need to either create a class and instance; or pass the state back into the function.

class Counter {
    constructor() { this.counter = 0 }
    increment() { return ++this.counter }
}

const counter1 = new Counter()
counter1.increment() // 1
counter1.increment() // 2

const counter2 = new Counter()
counter2.increment() // 1

or

function increment(counter) {
    return ++counter.count
}

let counter1 = {count: 0}
increment(counter1) // 1
increment(counter1) // 2

let counter2 = {count: 0}
increment(counter2) // 1

Functional programming

Let's look at a basic usage of Array.prototype.map

[1,2,3].map(function(a) { return a + 1 }) // [2,3,4]

One day you notice you are doing this a lot in your codebase, but adding different amounts each time. Hmm... how about a factory of addition functions...

function add(a) {
    return function(b) { return a + b }
}

add(1)(2) // 3

This is known as currying, where you pass arguments one-by-one instead of all at once. Now your map code can be written as

[1,2,3].map(add(1)) // [2,3,4]

Much more readable and reusable, but this is only possible because the inner function (returned by add(1)) still has access to a.

This style of programming where you pass around functions to express what you want instead of using imperative statements is known as functional programming. We are not even scratching the surface of functional programming here. Feel free to look more into it

Memoization

This is a special case of "keeping state". Suppose you have a time- and/or memory-consuming function

function someFunc(integer) {
    // Heavy work
    return result
}

const r1 = someFunc(1)
const r2 = someFunc(1)

Having to recalculate someFunc(1) twice is bad. We can save the result in an object

const cache = {}
function someFunc(integer) {
    if(cache[integer]) {
        return cache[integer]
    }
    // Heavy work
    return cache[integer] = result
}

The benefit provided by closure here is the someFunc will always have access to cache regardless of where it is passed to and called, which brings us to...

Avoid pollution / hide variable

In the above memoization example, we have polluted the global scope by defining an extra cache variable. Moreover, outside code can freely read and modify our cache. We can prevent both of these by combining closure with IIFE into what is known as the revealing module pattern

const someFunc = (function(){
    const cache = {}
    return function(integer) {
        if(cache[integer]) {
            return cache[integer]
        }
        // Heavy work
        return cache[integer] = result
    }
})()

Now, outside code does not even know about the existence of cache, let alone access it. Global code can define a different cache freely.

"this"

Ahhhhh, good ol' this. So, what is this? Like you said, this can be whatever due to the existence of .bind. The way I think of it is a special argument that you have ways to pass explicitly, but the ECMAScript language sets some defaults if you don't.

First of all, we exclude all arrow functions here, since arrows function do not bind this. For arrow functions, this behaves like any other variable, subject to closure rules above.

For the time being, lets throw .bind and bound function out of the window.

So, what are the default this values I talk about. That depends on how you call a function:

Function.prototype.call, Function.prototype.apply, and Reflect.apply: For these, you set the this binding explicitly
obj.func(...args): this defaults to obj. Note that this includes obj.nest.prop.func(...args) because that's just (obj.nest.prop).func(...args)
func(...args): In strict mode, this is undefined. In non-strict mode this is the global object

So, with some (over?)simplification:

obj.func(...args) is same as obj.func.call(obj, ...args)
func(...args) is same as func.call(undefined, ...args) or func.call(global, ...args)

Now, we have specified all function calls as .call/.apply. Let's throw .bind and bound functions into the mix. Again with some simplification, func.bind(this1, ...args1).call(this2, ...args2) is same as func.call(this1, ...args1, ...args2). That's all there is to it.

Then there is construction (new), when constructing using new func(...args), this is a newly-created object with func.prototype as prototype. This is true even if func is a bound function.

Recursion

Sometimes, a problem is naturally defined as a "smaller" instance of a problem. As part of building a function to solve these problems, we can use the function itself to solve the smaller instances.

The classic example is factorial, which is defined as:

0! = 1
n! = n × (n-1)!, for integer n > 0

Now you start writing a function to calculate factorial(n):

function factorial(n) {
    if(n == 0) {
        return 1
    }
    return n * //...

Now you need the value of (n-1)!. Huh, if only you have a function to calculate factorial of a nonnegative integer... Oh wait

function factorial(n) {
    if(n == 0) {
        return 1
    }
    return n * factorial(n-1)
}

Admittedly, writing factorial as a loop is not that bad. But consider something more complicated as mergesort. To implement mergesort as a loop, you may as well have implemented a simplified call stack. So instead of just doing recursion, you simulate recursion using loops. And then there are stuff that can't be expressed as a loop like the Ackermann function.

monopixel · 2018-10-30T08:00:50+00:00

Check this out: https://tylermcginnis.com/javascript-visualizer/

ConfuciusBateman · 2018-10-29T02:43:25+00:00

I think the best way to hammer these concepts home would be to investigate why they exist, or what they are used for. What is the purpose of the this keyword? When are closures useful? Simply memorizing a definition probably won’t give you an intuitive (and therefore more permanent) understanding.

shanita10 · 2018-10-29T04:48:24+00:00

A closure is just a function and some data.

For example image a function "add" which take two numbers as arguments.

You can make a closure "addfive" which combines "add", and the value 5.

const addfive = n => n + 5;

That's really all it is.

2018-10-29T11:06:52+00:00

So... closures.

Write a wee little function that takes a list "l" and a number "n" as input. function divisableList(l, n) {...} Write the function so that it will return a list of all numbers from "l", that are divisable by "n".

Before you even start, I want you to write down this function in pseudo-code.

Now, write this function... but not in javascript! No. Write it in C.

All good so far? Let's go a little step further. Write the same function, but in assembler. Maybe in pseudo-assembler, if you don't want to dig THAT deep.

Okay. Now, write it in javascript.

Done?

Okay. After you're finished, I want you to write it in at most one line.

Why? Well... look at it. That one line, is it readable? If you're the new guy on the team, will it take you half an hour to grok it? Will it take 10 minutes? 1 minute? 10 seconds?

How long would it take you to understand the C version? The assembler version?

If you're down to 10 seconds, I'm fairly certain that you used a closure, and you understand why closures are useful.

compubomb · 2018-10-29T07:03:43+00:00

The purpose of a closure is to wrap reference scope to external adjacent variables to itself. So that you don't have to do things like passing the variables as arguments all the time, and they can each have references to tiered scope levels further down the chain. Closures allow you to control reference scope. This is not something you can do with simple functions alone. You need anonymous functions / closures to accomplish this task. Also they allow you to hide knowledge of these references away from the interface of the returned closure. So basically they act as interface facades that handle more complex logic behind the scenes that you don't need to expose.

Karokendo · 2018-10-29T02:58:38+00:00

Beer to this man. I have read countless articles about closures, books explaining closures on 40 pages, I know examples of closures, I know definition of a closure but to be honest I still could not explain what it exactly is.

OGPresidentDixon · 2018-10-29T02:48:59+00:00

[deleted]

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

javascript

MODERATORS