
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.


memoization


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.
