### A normal function

Let’s declare the function:

``````var add = function(x, y) {
return x + y;
};
``````

Now, we can call the function using the variable `add`

``````> add(2, 3)
> 5
``````

If we omit parenthesis and arguments, we can also reference the function without calling it:

``````> add
> function (x,y) { return x+y; }
``````

2 things happen when we call `add(5, 3)`:

1. The `add` part is replaced (interpreted) with the function declaration (`function (x, y) { return x + y; }`,
2. Parenthesis are added, containing the arguments. Then the function is run.

So `add(3, 5)` is the same as:

``````> function(x, y) {
>   return x + y;
> }(3, 5)
> 5
``````

### Closures

A closure is a function that returns another function.
Let’s leverage the `add` function we just used to create a new function called `addTen`. It adds 10 to any number.

``````var addTen = function(x) {
}
``````

As we did above, we can now reference this function with the variable `addTen`. We must add parenthesis to run the function:

``````> addTen
> function (x) { return add(x, 10) }
>
> 15
``````

Now, `add(x, 10)` is printed when we reference the function. There are parenthesis, so it looks like we are calling `add`, but the function hasn’t been called yet.

Why?

The reason is Javascript’s double interpretation cycle.

The code is interpreted twice:

• at run time (when the code actually runs)

The first time the code is interpreted:

• All variables are replaced by what they actually hold. For instance, `add` is replaced by `function (x, y) { return x + y;}`
• All first level function calls run. `add(5,3)` runs and is replaced by `15`

What’s important is “first level”.
In the example of our closure, the `return add(x, 10)` part is “nested”. It lives inside another function, and won’t run unless the parent function is called.

Say you load the following file:

``````var add = function (x, y) {
return x + y;
};
var addTen = function (x) {
};

``````

The interpreted file, once loaded, looks like this: [footnote 1]

``````var add = function (x, y) {
return x + y;
};
var addTen = function (x) {
};

function (x, y) {
return x + y;
}
8

function (x) {
}
15
``````

That’s fucking important!! –>
In the example of our closure, when interpreting `addTen`, the part with `add(x, 10)` isn’t executed despite parenthesis. That’s because the parent is not being executed (`addTen` is without parenthesis).

### Passing around function references

Having the function declaration in the variable is useful to call it multiple times, and from different places. But it also to “pass it around”. For example, you can now pass it as an argument to another function.

Let’s say we add another math function called `multiple`:

``````var multiple = function (x, y) {
return x * y;
};
``````

And that instead of the `addTen` function, we want a `modeTen` function. It takes a number and an incrementation mode (add or multiple) and combines the number and 10 using this incrementation mode:

``````var modeTen = function(x, mode) {
return mode(x, 10);
};
``````

Here we can now call our `modeTen` function with a number and either our `add` or `multiple` function:

``````> modeTen(5, add)
> 15

> modeTen(5, multiple)
> 50
``````

### Why does it matter?

Referencing, passing and calling function is something we keep doing in javascript. For instance, with callbacks:

``````var functionWithCallback = function (name, callback) {
console.log("hello " + name);

callback(name);
};
``````

This is a very simple function that prints a name and calls a callback once it’s done.
The callback function could be just a function we use to let us know that the name was successfully printed:

``````var success = function(name) {
console.log("successfully printed " + name);
};

> functionWithCallback('jonathan', success);
> "hello jonathan"
> "successfully printed jonathan"
``````

Closures are often wrongfully abused to fix a bug coming from a bad understanding of all this. Look at an example using our previous `functionWithCallback`:

Let’s say you are using an API you are not really familiar with (could be something like `res.render` in nodejs), and you want to make sure that your callback will be called with the `name` variable. You might write something like this:

``````functionWithCallback('jonathan', success('jonathan'));
``````

You’re passing `success('jonathan')` as an argument. As we just saw, `success('jonathan')` will be called at load time. That means you end up passing the result of the function instead of the function itself:
`functionWithCallback('jonathan', 'successfully printed jonathan')`.

Not what you wanted.

But faced with a bug, and not understanding the issue, many engineers will mess around, and end up solving this problem with a closure:

``````functionWithCallback('jonathan', function() {
success('jonathan');
});
``````

They end up in this situation because this callback syntax looks familiar. It’s the syntax used to declare a callback inline, when it’s not in a variable.

The `success` function is being called inside `functionWithCallback` with `name` passed to it as we want. So it’s enough to simply pass a reference of the `success` function as argument. Using the `success` variable without parenthesis:

``````functionWithCallback(‘jonathan’, success);
``````

Another example is in React, when passing a function as a prop. Let’s say we have the following React component:

``````class Parent extends React.Component {
onButtonClick() {
console.log(‘clicked button‘);
}

render() {
<Button id=”1” onClick={this.onButtonClick} />
}
}
``````

In this example, we pass `onButtonClick` to the button component. When the button is clicked, the function is called, and all is good.

But, if the `onButtonClick` function had a `buttonId` argument, the button would not know about what argument to pass:

``````class Parent extends React.Component {
onButtonClick(id) {
console.log(‘clicked button ‘ + id); // we now pass an id as argument
}

render() {
<Button id=”1” onClick={this.onButtonClick} />  // Button has no idea what “id” is
}
}
``````

Since Button doesn’t know what “id” is, we need to explicitly tell the button what the id is and to pass it as an argument when calling the function.
One solution is to use a closure:

``````render() {
<Button id=”1” onClick={() => this.onButtonClick(“1”)} />
}
``````

In this case it would work, because thanks to the closure the inner function `this.onButtonClick(“1”)` is nested and doesn’t get called at load time.

Another solution would be to use an inner onClick function on the button component, which is often cleaner (in my opinion):

``````class Parent extends React.Component {
onButtonClick(id) {
console.log(‘clicked button ‘ + id);
}

render() {
<Button id=”1” onClick={this.onButtonClick} />
}
}

Class Button extends React.Component {
onClick() {
this.props.onClick(this.props.id);
}
}
``````

This is only possible if you control the element receiving the function as props. If the component was a native HTML `<button>` for instance, this wouldn’t be an option.

A last general comment about passing functions through multiple levels. In our example of the `onButtonClick` that takes an `id` as argument, you only have to explicitly pass the `id` argument in the component that will actually call the function, and can only pass the function by reference to other components it goes through;

``````class Root extends React.Component {
onButtonClick(id) {
console.log(‘clicked button ‘ + id);
}

render() {
<Section onButtonClick={this.onButtonClick} />
}
}

Class Section extends React.Component {
render() {
<button id=”1” onClick={() => this.onButtonClick(“1”)} />
}
}
``````

Note here the `onButtonClick` is from the `Root` component and we pass the function down to a button element, through the `Section` component. Despite choosing the closure solution, which we use on the props of the `button`, we don’t have to explicitly tell `Section` about the `id` argument and just pass it `onButtonClick` as a reference.

## What we learned

1. When declaring a function, using the variable holding this function only references the function, but doesn’t call it. You need to add parenthesis and arguments to call and execute a function.
2. A closure is a function that returns another function. It’s useful to create helper functions such as `addTen`, and in many other situations.
3. Finally, we saw how to use callbacks, pass them as an argument to another function, and use closures to avoid calling the callback at load time, when having to pass it with explicit arguments.

Hope this will help understand better the life cycle of your code and clean up some of your callbacks and unnecessary closures :)

[footnote 1] This is not entirely true as things get manipulated different ways (to dive deeper look at things like scope and encapsulation) and compiled to bytecode in something un-reable for humans. But I find giving this visual representation of the “compiled” file being very useful to understand what the code actually represents.