
Closures are confusing because they are an “invisible” concept.

When you use an object, a variable, or a function, you do this intentionally. You think: “I’m gonna need a variable here,” and add it to your code.

Closures are different. By the time most people approach closures, they have already used them unknowingly many times — and it is likely that this is true for yourself, too. So learning closures is less about understanding a *new* concept and more about recognizing something you have *already been doing* for a while.

### tl;dr

You have a closure when **a function accesses variables defined outside of it**.

For example, this code snippet contains a closure:

```js
let users = ['Alice', 'Dan', 'Jessica'];
let query = 'A';
let user = users.filter(user => user.startsWith(query));
```

Notice how `user => user.startsWith(query)` is itself a function. It uses the `query` variable. But the `query` variable is defined *outside* of that function. That’s a closure.

---

**You can stop reading here, if you want.** The rest of this article approaches closures in a different way. Instead of explaining what a closure is, it will walk you through the process of *discovering* closures — like the first programmers did in the 1960s.

---

### Step 1: Functions Can Access Outside Variables

To understand closures, we need to be somewhat familiar with variables and functions. In this example, we declare the `food` variable *inside* the `eat` function:

```js
function eat() {
  let food = 'cheese';
  console.log(food + ' is good');
}

eat(); // Logs 'cheese is good'
```

But what if we wanted to later change the `food` variable *outside* of the `eat` function? To do this, we can move the `food` variable itself out of our function into the top level:

```js
let food = 'cheese'; // We moved it outside

function eat() {
  console.log(food + ' is good');
}
```

This lets us change the `food` “from the outside” any time that we want to:

```js
eat(); // Logs 'cheese is good'
food = 'pizza';
eat(); // Logs 'pizza is good'
food = 'sushi';
eat(); // Logs 'sushi is good'
```

In other words, the `food` variable is no longer *local* to our `eat` function, but our `eat` function nevertheless has no trouble accessing it. **Functions can access variables outside of them.** Stop for a second and make sure that you have no problem with this idea. Once it has settled comfortably in your brain, move to the second step.

### Step 2: Wrapping Code in a Function Call

Let’s say we have some code:

```js
/* A snippet of code */
```

It doesn’t matter what that code does. But let’s say that **we want to run it twice**.

One way to do it would be to copy and paste it:

```js
/* A snippet of code */
/* A snippet of code */
```

Another way to do it would be to use a loop:

```js
for (let i = 0; i < 2; i++) {
  /* A snippet of code */
}
```

The third way, which we’re particularly interested in today, is to wrap it in a function:

```js
function doTheThing() {
  /* A snippet of code */
}

doTheThing();
doTheThing();
```

Using a function gives us the ultimate flexibility because we can run this function any number of times, at any time — and from anywhere in our program.

In fact, **we can even call our new function only *once***, if we wanted to:

```js
function doTheThing() {
  /* A snippet of code */
}

doTheThing();
```

Notice how the code above is equivalent to the original code snippet:

```js
/* A snippet of code */
```

In other words, **if we take some piece of code, “wrap” that code in a function, and then call that function exactly once, we haven’t changed what that code is doing**. There are some exceptions to this rule which we will ignore, but generally speaking this should make sense. Sit on this idea until your brain feels comfortable with it.

### Step 3: Discovering Closures

We have traced our way through two different ideas:

* **Functions can access variables defined outside of them.**
* **Wrapping code in a function and calling it once doesn’t change the result.**

Now let’s see what happens if we combine them.

We’ll take our code example from the first step:

```js
let food = 'cheese';

function eat() {
  console.log(food + ' is good');
}

eat();
```

Then we’ll wrap *this whole example* into a function, which we’re going to call once:

```js
function liveADay() {
  let food = 'cheese';

  function eat() {
    console.log(food + ' is good');
  }

  eat();
}

liveADay();
```

Read both snippets one more time and make sure that they are equivalent.

This code works! But look closer. Notice the `eat` function is *inside* the `liveADay` function. Is that even allowed? Can we really put a function inside another function?

There are languages in which a code structured this way is *not* valid. For example, this code is not valid in the C language (which doesn’t have closures). This means that in C, our second conclusion isn’t true — we can’t just take some arbitrary piece of code and wrap it in a function. But JavaScript doesn’t suffer from that limitation.

Take another good look at this code and notice where `food` is declared and used:

```js
function liveADay() {
  let food = 'cheese'; // Declare `food`

  function eat() {
    console.log(food + ' is good'); // Read `food`
  }

  eat();
}

liveADay();
```

Let’s go through this code together — step by step. First, we declare the `liveADay` function at the top level. We immediately call it. It has a `food` local variable. It also contains an `eat` function. Then it calls that `eat` function. Because `eat` is inside of `liveADay`, it “sees” all of its variables. This is why it can read the `food` variable.

**This is called a closure.**

**We say that there is a closure when a function (such as `eat`) reads or writes a variable (such as `food`) that is declared outside of it (such as in `liveADay`).**

Take some time to re-read this, and make sure you can trace this in the code.

Here is an example we’ve introduced in the tl;dr section:

```js
let users = ['Alice', 'Dan', 'Jessica'];
let query = 'A';
let user = users.filter(user => user.startsWith(query));
```

It may be easier to notice the closure if we rewrite it with a function expression:

```js
let users = ['Alice', 'Dan', 'Jessica'];
// 1. The query variable is declared outside
let query = 'A';
let user = users.filter(function(user) {
  // 2. We are in a nested function
  // 3. And we read the query variable (which is declared outside!)
  return user.startsWith(query);
});
```

Whenever a function accesses a variable that is declared outside of it, we say it is a closure. The term itself is used a bit loosely. Some people will refer to the *nested function itself* as “the closure” in this example. Others might refer to the *technique* of accessing the outside variables as the closure. Practically, it doesn’t matter.

### A Ghost of a Function Call

Closures might seem deceptively simple now. This doesn’t mean they’re without their own pitfalls. The fact that a function may read and write variables outside has rather deep consequences if you really think about it. For example, this means that these variables will “survive” for as long as the nested function may be called:

```js
function liveADay() {
  let food = 'cheese';

  function eat() {
    console.log(food + ' is good');
  }

  // Call eat after five seconds
  setTimeout(eat, 5000);
}

liveADay();
```

Here, `food` is a local variable inside the `liveADay()` function call. It’s tempting to think it “disappears” after we exit `liveADay`, and it won’t come back to haunt us.

However, inside of `liveADay` we tell the browser to call `eat` in five seconds. And `eat` reads the `food` variable. **So the JavaScript engine needs to keep the `food` variable from that particular `liveADay()` call available until `eat` has been called.**

In that sense, we can think of closures as of “ghosts” or “memories” of the past function calls. Even though our `liveADay()` function call has long finished, its variables must continue to exist for as long as the nested `eat` function may still be called. Luckily, JavaScript does that for us, so we don’t need to think about it.

### Why “Closures”?

Finally, you might be wondering why closures are called that way. The reason is mostly historical. A person familiar with the computer science jargon might say that an expression like `user => user.startsWith(query)` has an “open binding”. In other words, it is clear from it what the `user` is (a parameter), but it is not clear what `query` is in isolation. When we say “actually, `query` refers to the variable declared outside”, we are “closing” that open binding. In other words, we get a *closure*.

Not all languages implement closures. For example, in some languages like C, it is not allowed to nest functions at all. As a result, a function may only access its own local variables or global variables, but there is never a situation in which it can access a parent function’s local variables. Naturally, that limitation is painful.

There are also languages like Rust which implement closures, but have a separate syntax for closures and regular functions. So if you want to read a variable from outside a function, you would have to opt into that in Rust. This is because under the hood, closures may require the engine to keep the outer variables (called “the environment”) around even after the function call. This overhead is acceptable in JavaScript, but it can be a performance concern for the very low-level languages.

And with that, I hope you can get a closure on the concept of closures!

>If you prefer a more visual approach to the JavaScript fundamentals, check out [Just JavaScript](https://justjavascript.com/). It is my illustrated course in collaboration with [Maggie Appleton](https://maggieappleton.com/).


a closure


Broadly speaking, **composition is putting two or more different things together, and getting the same “kind” of thing — a combination of the inputs — as a result.**

The concrete meaning might depend on the context, so we’ll look at a few examples that come up in front-end JavaScript development.

### Composition in Math

While math is somewhat unrelated to front-end development, it’s useful to recap the [mathematical definition](https://en.wikipedia.org/wiki/Function_composition) — if only to show where the term originates.

Let’s say we have two functions. One function is `y = 2 * x`, which doubles its argument. The other function is `y = x + 10`, which adds 10 to its argument.

If we put them together so that the output of one function is fed to the other function, we get `y = (2 * x) + 10`. This is an example of composition — we’ve “composed” this function out of two other functions. **That’s all this term means.**

Note how composition of two functions gives us another function. It doesn’t give us something entirely different. As a result, we can keep composing it many times.

Composition is a broad term, but we will only use it when the result of putting things together is the same “kind” of thing — whether it’s a function, a component, etc.

### Function Composition

Composition often comes up in the context of functional programming. There, it refers to the same concept as in mathematics, but expressed in code.

Let’s say we have code like this:

```js
let date = getDate();
let text = formatDate(date);
let label = createLabel(text);
showLabel(label);
```

There is some repetition to this code. A [rhythm](https://twitter.com/dan_abramov/status/1216142369181093889), if you will. We take a thing, convert it to something else, take *that* thing, convert it to something else, and so on.

But can we go further and remove the repetition, leaving only the steps?

```js
let steps = [
  getDate,
  formatDate,
  createLabel,
  showLabel
];
```

Some might say this code is [cleaner](https://overreacted.io/goodbye-clean-code/).

Let’s write a function that we’ll call `runSteps` that applies each step one by one:

```js
function runSteps(steps) {
  let result;
  for (let i = 0; i < steps.length; i++) {
    let step = steps[i];
    // Apply next step in the chain
    result = step(result);
  }
  return result;
}
```

With this function, our original code becomes:

```js
runSteps([
  getDate,
  formatDate,
  createLabel,
  showLabel
]);
```

Now let’s say we want to perform all of these steps, but from different places in our program, and at different times. We could write a function that does this for us:

```js
function showDateLabel() {
  runSteps([
    getDate,
    formatDate,
    createLabel,
    showLabel
  ]);
}

// We can call it whenever!
showDateLabel();
showDateLabel();
```

Or we could have a function — we’ll call it `pipe` — that *generates* our function:

```js
let showDateLabel = pipe(
  getDate,
  formatDate,
  createLabel,
  showLabel
);

// We can call it whenever!
showDateLabel();
showDateLabel();
```

This code does exactly the same thing, but we didn’t have to explicitly implement `showDateLabel` (which merely called `runSteps`). We’ve [tucked it away](/closure) inside `pipe`:

```js
function pipe(...steps) {
  // Return a function that will do this for me
  return function runSteps() {
    let result;
    for (let i = 0; i < steps.length; i++) {
      let step = steps[i];
      result = step(result);
    }
    return result;
  }
}
```

This reusable function lets us rewrite our code so that **instead of manually calling functions one by one in a sequence, we only specify the steps**. We called it `pipe` because it “pipes” the output of each previous function to the next one.

Recall our original code:

```js
let date = getDate();
let text = formatDate(date);
let label = createLabel(text);
showLabel(label);
```

And this is what it looks like with `pipe`:

```js
let showDateLabel = pipe(
  getDate,
  formatDate,
  createLabel,
  showLabel
);
showDateLabel();
```

If you’re not sold on expressing everything using function composition, you might be wondering — what was the point? Why did we go through all of these steps? Isn’t the first example a bit more readable? Are you the only person not “getting” it?

#### Functional Eureka

Understanding `pipe` and function composition for the first time is a lightbulb moment. We don’t have to call our functions manually — instead, we can feed our functions to another function that will give us back a function to call our functions!

How “beautiful”.

There is definitely a profound insight there that we shouldn’t disregard. We have *raised the level of abstraction* by making the structure of our program itself — a sequence of steps — into something our code can manipulate. For example, we could teach `pipe` to wrap every step with some logging, or to run every step asynchronously. This is a powerful technique that deserves our understanding.

This programming style can also be a nightmare to work with. We’ve “outsourced” the actual business of function calls to helpers like `pipe`, and as a result we can no longer clearly see how each piece of data flows in and out of our functions because it all happens inside of `pipe`. We’ve added a piece of “indirection” — our code is more flexible, but less direct. Add too many layers, and [our heads will overflow](https://overreacted.io/the-wet-codebase/).

While this programming style can be used with great success (especially in strongly typed languages that enforce *which* things can “fit” into other things), it’s a tad overused by enthusiastic programmers who get a dopamine rush from writing clever one-liners and hiding the control flow in “elegant” helpers. I did that, too.

#### Function Composition Is Neat, Though

That being said, the fundamental idea of function composition is important. Essentially, it means that when we have `doX(doY(doZ(thing)))`, we can *first* compose `doX`, `doY`, and `doZ`, and *then* apply the resulting function together.

In the trivial cases like above, using it directly brings more trouble than it’s worth. But it might get more useful if the problem is more challenging. Perhaps, we want each step to be [memoized](/memoization). Perhaps, each step happens asynchronously and the control flow is more complex. There can be cases where we want something to happen before or after each step, without repeating that fragile logic everywhere. Perhaps, the steps themselves need to be “interpreted” in different ways by our program, so we want to separate their order from how they are being executed.

Function composition can inspire interesting solutions if we keep it mind. This doesn’t mean that we need to take out a `pipe` every time we want to put two functions together. We don’t need to prove to the computer that we’re smart and learned our lessons about composition. Usually, plain function calls are enough.

### Component Composition

Another context in which we might hear the word “composition” is related to declarative UI programming. We’ll take React components as an example.

React components render other components, all the way from `<App>` to a `<Button>`:

```js
function App() {
  return <Screen />;
}

function Screen() {
  return <Form />;
}

function Form() {
  return <Button />;
}

function Button() {
  return <button>Hey there.</button>;
}
```

This is also called “composition” because we are putting things (components) into other things (components), and they fit with each other (“compose”) pretty well.

One interesting variant of composition is when a component has “slots”:

```js
function Layout({ sidebar, content }) {
  return (
    <div>
      <div className="sidebar">{sidebar}</div>
      <div className="content">{content}</div>
    </div>
  )
}
```

Then we can “fill in” those slots from different parent components:

```js
function HomePage() {
  return (
    <Layout
      sidebar={<HomeSidebar />}
      content={<HomeContent />}
    >
  )
}

function AboutPage() {
  return (
    <Layout
      sidebar={<AboutSidebar />}
      content={<AboutContent />}
    >
  )
}
```

Note how these “slots” aren’t a special React feature. They are a consequence of our ability to pass down pieces of UI the same way we would pass any other data.

This is also called “composition” because we compose (“fill in”) `Layout` with different child components. Putting things inside other things.

### Composition vs Inheritance

People sometimes say “composition” when contrasting it with inheritance. This has less to do with functions (which we’ve been discussing all along) and more to do with objects and classes — that is, with traditional object-oriented programming.

In particular, if you express your code as classes, it is tempting to reuse behavior from another class by extending it (inheritance). However, this makes it somewhat difficult to adjust the behavior later. For example, you may want to similarly reuse behavior from *another* class, but you can’t extend more than one base class.

Sometimes, people say that inheritance “locks you into” your first design because the cost of changing the class hierarchy later is too high. When people suggest *composition* is an alternative to inheritance, they mean that instead of extending a class, you can keep an instance of that class as a field. Then you can “delegate” to that instance when necessary, but you are also free to do something different.

Overall, the industry has largely moved away from modeling UI components as deep inheritance hierarchies, as was common in the 2000s.

This doesn’t mean inheritance is always “bad”. But it is a very blunt tool, and it should be approached with moderation. In particular, inheritance hierarchies deeper than a few levels often cause problems that shallow inheritance doesn’t.

Modern front-end codebases rarely use inheritance for their UI because all of the popular UI libraries today feature powerful built-in support for composition. Say, in React, instead of extending a `Button`, you would *render* a `<Button>` in a parent component. Even JavaScript UI libraries that embrace classes typically don’t use inheritance as a way to reuse rendering code. And this is probably for the best.

### Recap

To sum up, we say that we compose two things when we make a third thing out of them that is similarly shaped. The term has a mathematical meaning, and it is close to its meaning in functional programming. But the further we move away from pure functional programming, the less formal and more colloquial this term becomes.

Function composition is a powerful concept, but it raises the level of abstraction and makes your code less direct. If you write your code in a style that composes functions in some way before calling them, and there are other humans on your team, make sure that you’re getting concrete benefits from this approach. It is not “cleaner” or “better”, and there is a price to pay for “beautiful” but indirect code.


composition


In JavaScript, we use *dynamic dispatch* whenever we call a method on an object:

```js
obj.method();
```

In some object-oriented languages that predate JavaScript (notably, in Smalltalk), “calling a method on an object” was known as “sending a message to an object”. The words “dispatch” and “send” are synonyms, which explains the term’s origin.

Why do we say this is “dynamic dispatch”? Can it be static? This depends on the language. For example, in JavaScript, calls like `obj.method()` are always “dynamic”. But this is not universally true for other languages. Let’s unpack the difference.

To understand this, we need to dive deeper into how computer code works under the hood. Generally speaking, the functions we write eventually become sequences of computer instructions that are stored somewhere in memory. Calling a function means the computer will “jump” to its code in memory and execute its operations.

When we say that a language has *static dispatch*, it means that when the computer compiles `obj.method()`, it knows exactly *which* function this code would “jump” to. It won’t need to do any extra operations to “find” the function location in memory.

**When we say that a language has *dynamic dispatch*, it means we can’t be 100% sure which function `obj.method()` will call until this code runs**. For example, any JavaScript engine would need to take the current value of the `obj` variable, search for a property called `method` on that object, keep searching for it on the prototype chain if needed — and finally, “jump” into the function (or error if it wasn’t found).

Static dispatch is more commonly found in lower-level languages like C++ where performance must stay very close to metal. Dynamic dispatch lets us write more expressive code, but at a slight performance cost. This cost is negligible in most scenarios in web development, and JavaScript engines do a really good job to optimize the common cases and make dynamic dispatch as cheap as possible. So in practice, this difference is rarely relevant to JavaScript application development.

In fact, because of the JavaScript engine optimizations, the end result may be counterintuitive. For example, modern JS engines can often optimize a dynamic `obj.method()` call to match performance of a static call in a running program as long as their initial assumptions about your object remain true. The inverse may also happen, where a `fn()` call that seemingly doesn’t involve “searching” for properties, may still require some extra steps. Small benchmarks are usually [a lie](https://mrale.ph/blog/2014/12/24/array-length-caching.html), so you should generally let the engine do its job and write the code in the most natural way to you.

**To sum up,** “dynamic dispatch” means that when we write `obj.method()`, the JS engine may need to “find” our function before it can call it. But in JavaScript, the distinction is fuzzy because at the micro level, the exact steps that happen may change between different concrete examples and even between browser versions.

Unless you’re specifically talking about the tradeoffs of `obj.method()` versus `fn()` calls or comparing different programming languages, saying “method call” is clearer.


dynamic dispatch


Before we start, let’s make sure we don’t confuse memoization and memorization. Memorization is when you put something in *your* head. It has the letter “r” in it.

But *memoization* (no “r”) is a nerdy computer science topic. Although in practice it also (unsurprisingly!) has to do with remembering things, there exist snobs who will hold it against you if you say “memorize” when you really mean “memoize”. I am not personally one of them, but you’ll need to keep this in mind for some job interviews.

Okay, if these are different things, then what *is* memoization?

### tl;dr

To illustrate it, imagine you’re writing a JavaScript app that calculates the weather based on the atmosphere readings. You don’t know how to do it, but luckily, there is an npm package with a `getChanceOfRain` function that you can use from your code:

```js
import { getChanceOfRain } from 'magic-weather-calculator';

function showWeatherReport() {
  let result = getChanceOfRain(); // Let the magic happen
  console.log("The chance of rain tomorrow is:", result);
}
```

There is just one problem. No matter what you do, calling `getChanceOfRain()` takes 100 milliseconds. So if the user rage-clicks “Show me the weather!” button, the weather will have to be recalculated and the app will briefly freeze on every click:

```js
showWeatherReport(); // (!) Triggers the calculation
showWeatherReport(); // (!) Triggers the calculation
showWeatherReport(); // (!) Triggers the calculation
```

This is not ideal. In the real life, if you already knew the answer, you wouldn’t be calculating it over and over! You would reuse the result from your previous calculation. That’s what memoization is. **Memoization means storing the result so you can use it next time instead of calculating the same thing again and again.**

In the below example, we call `memoizedGetChanceOfRain()` instead. This is a new function that we added which will check if we already have an answer — and if we do, it will return the previous answer instead of re-running `getChanceOfRain()`:

```js
import { getChanceOfRain } from 'magic-weather-calculator';

let isCalculated = false;
let lastResult;

// We added this function!
function memoizedGetChanceOfRain() {
  if (isCalculated) {
    // No need to calculate it again.
    return lastResult;
  }
  // Gotta calculate it for the first time.
  let result = getChanceOfRain();
  // Remember it for the next time.
  lastResult = result;
  isCalculated = true;
  return result;
}

function showWeatherReport() {
  // Use the memoized function instead of the original function.
  let result = memoizedGetChanceOfRain();
  console.log("The chance of rain tomorrow is:", result);
}
```

This makes every call to `showWeatherReport()` except the first one instant:

```js
showWeatherReport(); // (!) Triggers the calculation
showWeatherReport(); // Uses the calculated result
showWeatherReport(); // Uses the calculated result
showWeatherReport(); // Uses the calculated result
```

That’s what memoization is. When we say a function is “memoized”, it doesn’t mean we do something special to it from the JavaScript language perspective. It only means that we avoid calling it unnecessarily if we know its result won’t change.

---

**You can stop reading here, if you want.** We’ll continue with a few extra details.

---

### Memoization and Parameters

Generally, memoization always follows the same scheme:

1. Check if we already have a result.
2. If yes, return it.
3. If no, calculate the result and store it for the next time.

However, the actual implementation depends on our circumstances. For example, let’s say that the `getChanceOfRain` function takes a `city` parameter:

```js
function showWeatherReport(city) {
  let result = getChanceOfRain(city); // Pass the city
  console.log("The chance of rain tomorrow is:", result);
}
```

If we naïvely memoized this function like we did before, we would introduce a bug:

```js
showWeatherReport('Tokyo');  // (!) Triggers the calculation
showWeatherReport('London'); // Uses the calculated answer
```

Do you see the bug yet? The weather in Tokyo and London might be very different, so we can’t safely reuse the previous answer. This means that **when we memoize a function and reuse its result, we have to take its parameters into account too**.

#### Solution 1: Only Keep the Last Result

The easiest solution to our example is to remember both the result *and* the parameters for which that result was calculated. Here is how we could do it:

```js
import { getChanceOfRain } from 'magic-weather-calculator';

let lastCity;
let lastResult;

function memoizedGetChanceOfRain(city) {
  if (city === lastCity) { // Notice this check!
    // Same parameters, so we can reuse the last result.
    return lastResult;
  }
  // Either we're called for the first time,
  // or we're called with different parameters.
  // We have to perform the calculation.
  let result = getChanceOfRain(city);
  // Remember both the parameters and the result.
  lastCity = city;
  lastResult = result;
  return result;
}

function showWeatherReport(city) {
  // Pass the parameters to the memoized function.
  let result = memoizedGetChanceOfRain(city);
  console.log("The chance of rain tomorrow is:", result);
}
```

Notice how this example is subtly different from our original one. Instead of *always* returning the last result when it exists, we check `city === lastCity` first. If the city changes midway, we’re going to have to re-calculate the result again:

```js
showWeatherReport('Tokyo');  // (!) Triggers the calculation
showWeatherReport('Tokyo');  // Uses the calculated result
showWeatherReport('Tokyo');  // Uses the calculated result
showWeatherReport('London'); // (!) Triggers the calculation
showWeatherReport('London'); // Uses the calculated result
```

This fixes our bug, but it’s not always an optimal solution. In particular, if our `city` parameter changes on every function call, our memoization becomes useless:

```js
showWeatherReport('Tokyo');  // (!) Triggers the calculation
showWeatherReport('London'); // (!) Triggers the calculation
showWeatherReport('Tokyo');  // (!) Triggers the calculation
showWeatherReport('London'); // (!) Triggers the calculation
showWeatherReport('Tokyo');  // (!) Triggers the calculation
```

Whenever you add memoization, remember to check if it actually helps!

#### Solution 2: Keep Many Results

Another thing we could do is to keep *many* results instead of just the last one. Although we could define variables like `lastTokyoResult`, `lastLondonResult`, and so on, it is much easier to use a [`Map`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Map) which lets us hold a result for every `city` value:

```js
// Remember the last result *for every city*.
let resultsPerCity = new Map();

function memoizedGetChanceOfRain(city) {
  if (resultsPerCity.has(city)) {
    // We already have a result for this city.
    return resultsPerCity.get(city);
  }
  // We're called for the first time for this city.
  let result = getChanceOfRain(city);
  // Remember the result for this city.
  resultsPerCity.set(city, result);
  return result;
}

function showWeatherReport(city) {
  // Pass the parameters to the memoized function.
  let result = memoizedGetChanceOfRain(city);
  console.log("The chance of rain tomorrow is:", result);
}
```

This solution works great for our use case because it only ever calculates the result the first time it encounters a particular value of `city`. Every next call with the same `city` parameter will reuse the previously calculated result that we stored in our `Map`:

```js
showWeatherReport('Tokyo');  // (!) Triggers the calculation
showWeatherReport('London'); // (!) Triggers the calculation
showWeatherReport('Tokyo');  // Uses the calculated result
showWeatherReport('London'); // Uses the calculated result
showWeatherReport('Tokyo');  // Uses the calculated result
showWeatherReport('Paris');  // (!) Triggers the calculation
```

However, this solution isn’t without its downsides too. **In particular, if we keep passing more different `city` values to our function, our `Map` will keep growing.**

So this solution trades faster performance for potentially unbounded memory growth. In the very worst cases, this can result in our browser tab crashing, especially if every result uses a significant part of memory (e.g. a DOM tree).

#### Other Solutions

There are many solutions on the spectrum between “keep only the last result” and “keep all results”. For example, you may keep results for the last N parameter values, which is known as an LRU, or a “least recently used”, cache. It’s nothing more than a Map with extra logic. You may also decide to *remove* past results after some time passes — similar to how browsers removes the cached assets after they expire. If our parameter were an object (rather than a string, like it is above), we could use [`WeakMap`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/WeakMap) instead of `Map` in modern browsers. The benefit of `WeakMap` is that it would automatically “clean up” the entries when our object key is no longer accessible. Memoization is a flexible technique, and you can choose between many tradeoffs.

### Memoization and Purity

We should note memoization isn’t always safe to do.

For example, imagine that the `getChanceOfRain` function from our magical npm package does not receive `city` as a parameter, but shows an input box to the user:

```js
// Inside the magical npm package
function getChanceOfRain() {
  // Show the input box!
  let city = prompt('Where do you live?');
  // ... calculation ...
}


// Our code
function showWeatherReport() {
  let result = getChanceOfRain();
  console.log("The chance of rain tomorrow is:", result);
}
```

If we call `showWeatherReport()` two times, we will see two input boxes. We could input different cities, and see different results in the console. But if we memoized the `getChanceOfRain` function, we would only see one input box! Each next call would keep returning the same result and wouldn’t let us enter a different city.

So memoization is only safe to do when the function is “pure” — that is, **if it only reads its parameters and doesn’t interact with the “outside world”.** With a pure function, it doesn’t matter whether you call it once or if you reuse its previous result.

This is why in a complex algorithm, it can be beneficial to separate the parts that *do* something from the parts that merely *calculate* something. The parts that calculate something can be pure, so they can be safely memoized and skipped on repeated calls. But the code that *does* something can’t be skipped without behavior changes:

```js
// If this function only calculates things,
// we would call it "pure".
// It is safe to memoize this function.
function getChanceOfRain(city) {
  // ... calculation ...
}


// This function is "impure" because
// it shows a prompt to the user.
function showWeatherReport() {
  // The prompt is now here
  let city = prompt('Where do you live?');
  let result = getChanceOfRain(city);
  console.log("The chance of rain tomorrow is:", result);
}
```

Now it would be safe to memoize `getChanceOfRain` — because it takes `city` as a parameter rather than showing the input box to the user. In other words, it is pure. Concretely, it would mean that you would still see an input box on every call to `showWeatherReport`, but the calculation would be skipped if we had the result.

### Reusable Memoization

If you want to memoize several functions, it can be annoying to repeat the same steps every time: add a variable, check if we have the result, store the result.

Luckily, we have a tool at our disposal — *functions!* — that lets us automate this. **We will use a function to “write” this repetitive memoization logic for us.**

Let’s take our first example that memoizes the last result:

```js
let isCalculated = false;
let lastResult;

function memoizedGetChanceOfRain() {
  if (isCalculated) {
    return lastResult;
  }
  let result = getChanceOfRain();
  lastResult = result;
  isCalculated = true;
  return result;
}
```

Then let’s wrap it all (without any changes) in a function called `memoize`:

```js
function memoize() {
  let isCalculated = false;
  let lastResult;

  function memoizedGetChanceOfRain() {
    if (isCalculated) {
      return lastResult;
    }
    let result = getChanceOfRain();
    lastResult = result;
    isCalculated = true;
    return result;
  }
}
```

We want to make this function more useful than just calculating the chance of rain. So instead of `getChanceOfRain`, we’ll add a function parameter that we’ll call `fn`:

```js
function memoize(fn) { // Declare the fn parameter
  let isCalculated = false;
  let lastResult;

  function memoizedGetChanceOfRain() {
    if (isCalculated) {
      return lastResult;
    }
    let result = fn(); // Call the passed function
    lastResult = result;
    isCalculated = true;
    return result;
  }
}
```

Finally, let’s also rename `memoizedGetChanceOfRain` to `memoizedFn` and *return* it:

```js
function memoize(fn) {
  let isCalculated = false;
  let lastResult;

  return function memoizedFn() { // Return the generated function!
    if (isCalculated) {
      return lastResult;
    }
    let result = fn();
    lastResult = result;
    isCalculated = true;
    return result;
  }
}
```

What we got as a result is a *reusable* function that does memoization for us.

Now our original example could shrink to this:

```js
import { getChanceOfRain } from 'magic-weather-calculator';

// Instead of writing it by hand, generate it.
let memoizedGetChanceOfRain = memoize(getChanceOfRain);

function showWeatherReport() {
  let result = memoizedGetChanceOfRain();
  console.log("The chance of rain tomorrow is:", result);
}
```

The `isCalculated` and `lastResult` variables still exist, but they are neatly tucked away inside the `memoize` function. In other words, they are part of a [closure](/closure). We can now use `memoize` anywhere, with each call to `memoize` independent from the others:

```js
import { getChanceOfRain, getNextEarthquake, getCosmicRaysProbability } from 'magic-weather-calculator';

// Each of these generated functions has its own lastResult and isCalculated.
// It's like if we wrote each of them by hand, but shorter.
let memoizedGetChanceOfRain = memoize(getChanceOfRain);
let memoizedGetNextEarthquake = memoize(getNextEarthquake);
let memoizedGetCosmicRaysProbability = memoize(getCosmicRaysProbability);
```

Here, the goal of `memoize` is to *generate a memoized version* of the function we provide to it, so that we don’t have to write each of them by hand every time.

A reusable `memoize` function like this exists in [Lodash](https://lodash.com/docs/4.17.15#memoize) and many other packages.

### Recap

Now let’s quickly recap what we learned. Memoization (without “r”) is a way to make your program faster. It works when there is a section of code that executes many times, but that code only performs a calculation (in other words, it is “pure”) — so it is safe to reuse the previous result. There are different approaches to memoization: you can memoize only the last result, the last N results, or even all previous results. You should use your judgement to choose the approach that makes sense in each specific case. Generally speaking, it is not hard to implement memoization manually, but there are also packages that do that for you. Here is how Lodash [implements it](https://github.com/lodash/lodash/blob/master/memoize.js).

But at its core, memoization is about taking code like this:

```js
import { getChanceOfRain } from 'magic-weather-calculator';

function showWeatherReport() {
  let result = getChanceOfRain();
  console.log("The chance of rain tomorrow is:", result);
}
```

And turning it into this:

```js
import { getChanceOfRain } from 'magic-weather-calculator';

let isCalculated = false;
let lastResult;

function memoizedGetChanceOfRain() {
  if (isCalculated) {
    return lastResult;
  }
  let result = getChanceOfRain();
  lastResult = result;
  isCalculated = true;
  return result;
}

function showWeatherReport() {
  let result = memoizedGetChanceOfRain();
  console.log("The chance of rain tomorrow is:", result);
}
```

Use memoization wisely and only where it brings concrete performance improvements. Otherwise, you’re adding complexity and potential bugs.
