
One thing I've seen people struggling with when it comes to testing a web
application is what to test and how. This post explains the approach I follow at
work and for my projects.

The examples will be based on React Testing Library, but the same concepts apply
just as well to any other frontend technology.

## You already know how to test

The first thing to understand is that you already know how to test. In fact, if
you have developed any application, you have tested it.

Do you remember when you were learning how to code, and you wrote your first
program? Chances are it looked something like this:

```js
console.log("Hello, world!");
```

You then executed your script, and sure enough, you read "Hello, world!" in the
console. That was a test. You were testing that your program was working as
expected.

If you think about it, that's what you still do for every program you create.
You write some code and then execute it to make sure it works.

Now imagine you get a bug report. Apparently, some feature stopped working. What
do you do first? You try to reproduce the bug by using your application. Again,
you are manually testing.

Manually testing is a very effective way to ensure your software is working.
Interacting with a portion of your application gives you confidence that it
works.

Of course, manual tests have a big problem: you need a person to run them. Even
a small application can quickly become hard to test manually. On top of that,
consider that you must "run" all your tests every time you introduce a small
change.

This is where testing libraries come into play. For me, these tools are a way to
automate the way I would manually test my application.

## An example

Let's go through a more concrete example to understand what I mean by
"automating the way I would manually test."

Suppose we are working on a simple currency converter application like this one:

<iframe style="width: 100%;" src="https://currency-converter-delta.vercel.app/"></iframe>

You can find the complete code
[here](https://github.com/Gpx/currency-converter).

Let's not get into the code just yet. What we should ask ourselves now is "How
would I manually test this app?" I would do something like this:

1. Check that we see a loading message until the app is ready
2. Check that we see the initial conversion for 1 Euro to Dollars
3. Change the amount and see that the conversion is updated
4. Change the currency and see that the conversion is updated

I think this makes for a reasonable test case. What we need to do now is trying
to automate it. I'm going to do that using React Testing Library, but the same
principles apply to most testing tools.

```jsx
test("renders learn react link", () => {
  render(<App />);
  // 1. Check that we see a loading message until the app is ready
  // 2. Check that we see the initial conversion for 1 Euro to Dollars
  // 3. Change the amount and see that the conversion is updated
  // 4. Change the currency and see that the conversion is updated
});
```

This is our basic setup that doesn't do much at the moment. Let's implement the
first step.

```jsx
test("renders learn react link", () => {
  render(<App />)
  // 1. Check that we see a loading message until the app is ready
  expect(screen.getByText("Loading...")).toBeInTheDocument();
  await waitForElementToBeRemoved(() => screen.getByText("Loading..."));

  // 2. Check that we see the initial conversion for 1 Euro to Dollars
  // 3. Change the amount and see that the conversion is updated
  // 4. Change the currency and see that the conversion is updated
});
```

Don't worry if you are not familiar with the particular API I'm using. The
important concept to get is that we're simulating what a user would do. First,
checking that the loading message is on the page and then waiting for it do
disappear.

Let's move on to step two:

```jsx
test("renders learn react link", () => {
  render(<App />)
  // 1. Check that we see a loading message until the app is ready
  expect(screen.getByText("Loading...")).toBeInTheDocument();
  await waitForElementToBeRemoved(() => screen.getByText("Loading..."));

  // 2. Check that we see the initial conversion for 1 Euro to Dollars
  const input = screen.getByDisplayValue("1");
  expect(screen.getByText(/1.08/)).toBeInTheDocument();

  // 3. Change the amount and see that the conversion is updated
  // 4. Change the currency and see that the conversion is updated
});
```

Here we are getting the input and checking that the converted value is on the
page.

Step three and four are quite similar so we can group them:

```jsx
test("renders learn react link", () => {
  render(<App />)
  // 1. Check that we see a loading message until the app is ready
  expect(screen.getByText("Loading...")).toBeInTheDocument();
  await waitForElementToBeRemoved(() => screen.getByText("Loading..."));

  // 2. Check that we see the initial conversion for 1 Euro to Dollars
  const input = screen.getByDisplayValue("1");
  expect(screen.getByText(/1.08/)).toBeInTheDocument();

  // 3. Change the amount and see that the conversion is updated
  fireEvent.change(input, { target: { value: "2" } });
  expect(screen.getByText(/2.16/)).toBeInTheDocument();

  // 4. Change the currency and see that the conversion is updated
  const select = screen.getByDisplayValue("USD");
  fireEvent.change(select, { target: { value: "RUB" } });
  expect(screen.getByText(/137.94/)).toBeInTheDocument();
});
```

And that's about it. We automated what a user would do to test this app. Notice
that the test knows nothing about the implementation details. We didn't have to
read the source code. This app could have been written in any frontend
framework, and the test would be the same.

There's only one last step missing. Our code is fetching the conversion rates.
It's always better not to make any real network calls in the tests, so we're
going to mock it. You can find a longer explanation on how to do that
[here](https://www.polvara.me/posts/how-to-test-asynchronous-methods/).

```jsx
import fetchRates from "./fetchRates";
jest.mock("./fetchRates");

test("renders learn react link", () => {
  fetchRates.mockResolvedValueOnce({ RUB: 68.9685, USD: 1.0816 });
  render(<App />)

  // 1. Check that we see a loading message until the app is ready
  expect(screen.getByText("Loading...")).toBeInTheDocument();
  await waitForElementToBeRemoved(() => screen.getByText("Loading..."));

  // 2. Check that we see the initial conversion for 1 Euro to Dollars
  const input = screen.getByDisplayValue("1");
  expect(screen.getByText(/1.08/)).toBeInTheDocument();

  // 3. Change the amount and see that the conversion is updated
  fireEvent.change(input, { target: { value: "2" } });
  expect(screen.getByText(/2.16/)).toBeInTheDocument();

  // 4. Change the currency and see that the conversion is updated
  const select = screen.getByDisplayValue("USD");
  fireEvent.change(select, { target: { value: "RUB" } });
  expect(screen.getByText(/137.94/)).toBeInTheDocument();

  expect(fetchRates).toHaveBeenCalledWith();
  expect(fetchRates).toHaveBeenCalledTimes(1);
});
```

## Units and integrations don't matter that much

At this point, people usually have two kinds of reactions. Some are hooked and
start writing tests this way—if you are, welcome to the club.

The second kind of reaction is usually a generic fear about the lack of unit
tests, namely the fact that these kinds of tests look more like integration,
end-to-end, or feature tests. For some people, you need to have 100% test
coverage with unit tests before you can do anything else.

If you are in this second category, allow me to tell you that in most
applications, 100% unit test coverage is not needed. It is usually a bad
practice.

Please don't take me wrong, unit tests can be useful for some occasions, but
writing higher-level tests is almost always better. The reason we write tests is
to make sure our app works. Writing a test that simulates a user interacting
with your app is what will give you the most confidence.

Unit tests are just checking that a small portion of your software is doing what
it's supposed to do. You can have 100% coverage with unit tests, but that gives
you no guarantee that the single parts are working well together.

## Why not E2E tests then?

If tests that simulate the user are so great, why not only writing end-to-end
tests (also known as browser tests or Selenium tests)? These are tests that run
inside a browser and connect to a real API.

E2E tests are great because they test your application in a real browser
environment. They have two drawbacks, though. They are slow to run, and they are
usually unstable.

To run them, you have to start a browser, run your application, and potentially
start your backend too. There are many more parts involved, and This leads to a
higher risk of something going wrong.

In general, I write E2E tests only to cover critical features and only the happy
paths (no errors, no edge cases).

## Conclusions

To sum it up, here's my strategy when it comes to testing:

1. Manually test my code
2. Write a test to simulate the way I manually test
3. Add an E2E test if the feature is critical


My Approach When It Comes to Testing


I've just sold myself to the gods of click-baiting by making an "x things you
didn't know about y" post. But hey, at least there no subtitle that says "number
three will blow your mind!"

Jokes aside the items in this list are concepts that I usually see beginners
struggling with. At the same time, learning these concepts will vastyly improve
your testing game. I know it did with mine.

## 1. Everything is a DOM node

This is usually the first misconception that beginners have when they start
approaching Testing Library. It is especially true for those developers like me
that came from [Enzyme](https://airbnb.io/enzyme/).

Many think that `getByText` and other helper methods return some special wrapper
around the React component. People even ask how to implement a
`getByReactComponent` helper.

When you work with Testing Library you are dealing with
[DOM nodes](https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model).
This is made clear by the first
[Guiding Principle](https://testing-library.com/docs/guiding-principles):

> If it relates to rendering components, then it should deal with DOM nodes
> rather than component instances, and it should not encourage dealing with
> component instances.

If you want to check for yourself, it's as simple as this:

```jsx
import React from "react";
import { render, screen } from "@testing-library/react";

test("everything is a node", () => {
  const Foo = () => <div>Hello</div>;
  render(<Foo />);
  expect(screen.getByText("Hello")).toBeInstanceOf(Node);
});
```

Once you realize that you're dealing with DOM nodes you can start taking
advantage of all the DOM APIs like
[`querySelector`](https://developer.mozilla.org/en-US/docs/Web/API/Element/querySelector)
or
[`closest`](https://developer.mozilla.org/en-US/docs/Web/API/Element/closest):

```jsx
import React from "react";
import { render, screen } from "@testing-library/react";

test("the button has type of reset", () => {
  const ResetButton = () => (
    <button type="reset">
      <div>Reset</div>
    </button>
  );
  render(<ResetButton />);
  const node = screen.getByText("Reset");

  // This won't work because `node` is the `<div>`
  // expect(node).toHaveProperty("type", "reset");

  expect(node.closest("button")).toHaveProperty("type", "reset");
});
```

## 2. `debug`'s optional parameter

Since we now know that we're dealing with a DOM structure, it would be helpful
to be able to "see" it. This is what
[`debug`](https://testing-library.com/docs/react-testing-library/api#debug) is
meant for:

```jsx
const { debug } = render(<MyComponent />);
debug();
```

Sometimes thought `debug`'s output can be very long and difficult to navigate.
In those cases, you might want to isolate a subtree of your whole structure. You
can do this easily by passing a node to `debug`:

```jsx
const { debug } = render(<MyComponent />);
const button = screen.getByText("Click me").closest();
debug(button);
```

## 3. Restrict your queries with `within`

Imagine you're testing a component that renders this structure:

```html
<table>
  <thead>
    <tr>
      <th>ID</th>
      <th>Fruit</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>1</td>
      <td>Apples</td>
    </tr>
    <tr>
      <td>2</td>
      <td>Oranges</td>
    </tr>
    <tr>
      <td>3</td>
      <td>Apples</td>
    </tr>
  </tbody>
</table>
```

You want to test that each ID gets its correct value. You can't use
`getByText('Apples')` because there are two nodes with that value. Even if that
wasn't the case you have no guarantee that the text is in the correct row.

What you want to do is to run `getByText` only inside the row you're considering
at the moment. This is exactly what
[`within`](https://testing-library.com/docs/dom-testing-library/api-helpers#within-and-getqueriesforelement-apis)
is for:

```jsx
import React from "react";
import { render, screen, within } from "@testing-library/react"; // highlight-line
import "jest-dom/extend-expect";

test("the values are in the table", () => {
  const MyTable = ({ values }) => (
    <table>
      <thead>
        <tr>
          <th>ID</th>
          <th>Fruits</th>
        </tr>
      </thead>
      <tbody>
        {values.map(([id, fruit]) => (
          <tr key={id}>
            <td>{id}</td>
            <td>{fruit}</td>
          </tr>
        ))}
      </tbody>
    </table>
  );
  const values = [
    ["1", "Apples"],
    ["2", "Oranges"],
    ["3", "Apples"],
  ];
  render(<MyTable values={values} />);

  values.forEach(([id, fruit]) => {
    const row = screen.getByText(id).closest("tr");
    // highlight-start
    const utils = within(row);
    expect(utils.getByText(id)).toBeInTheDocument();
    expect(utils.getByText(fruit)).toBeInTheDocument();
    // highlight-end
  });
});
```

## 4. Queries accept functions too

You have probably seen an error like this one:

```text
Unable to find an element with the text: Hello world.
This could be because the text is broken up by multiple elements.
In this case, you can provide a function for your text
matcher to make your matcher more flexible.
```

Usually, it happens because your HTML looks like this:

```html
<div>Hello <span>world</span></div>
```

The solution is contained inside the error message: "[...] you can provide a
function for your text matcher [...]".

What's that all about? It turns out matchers accept strings, regular expressions
or functions.

The function gets called for each node you're rendering. It receives two
arguments: the node's content and the node itself. All you have to do is to
return `true` or `false` depending on if the node is the one you want.

An example will clarify it:

```jsx
import { render, screen, within } from "@testing-library/react";
import "jest-dom/extend-expect";

test("pass functions to matchers", () => {
  const Hello = () => (
    <div>
      Hello <span>world</span>
    </div>
  );
  render(<Hello />);

  // These won't match
  // getByText("Hello world");
  // getByText(/Hello world/);

  screen.getByText((content, node) => {
    const hasText = (node) => node.textContent === "Hello world";
    const nodeHasText = hasText(node);
    const childrenDontHaveText = Array.from(node.children).every(
      (child) => !hasText(child)
    );

    return nodeHasText && childrenDontHaveText;
  });
});
```

We're ignoring the `content` argument because in this case, it will either be
"Hello", "world" or an empty string.

What we are checking instead is that the current node has the right
[`textContent`](https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent).
`hasText` is a little helper function to do that. I declared it to keep things
clean.

That's not all though. Our `div` is not the only node with the text we're
looking for. For example, `body` in this case has the same text. To avoid
returning more nodes than needed we are making sure that none of the children
has the same text as its parent. In this way we're making sure that the node
we're returning is the smallest—in other words the one closes to the bottom of
our DOM tree.

## 5. You can simulate browsers events with `user-event`

Ok, this one is a shameless plug since I'm the author of `user-event`. Still,
people—myself included—find it useful. Maybe you will too.

All `user-event` tries to do is to simulate the events a real user would do
while interacting with your application. What does it mean? Imagine you have an
`input` field, and in your tests, you want to enter some text in it. You would
probably do something like this:

```jsx
fireEvent.change(input, { target: { value: "Hello world" } });
```

It works but it doesn't simulate what happens in the browser. A real user would
most likely move the mouse to select the input field and then start typing one
character at the time. This, in turns, fires many events (`blur`, `focus`,
`mouseEnter`, `keyDown`, `keyUp`...). `user-event` simulates all those events
for you:

```jsx
import userEvent from "@testing-library/user-event";

userEvent.type(input, "Hello world");
```

Check out the
[README](https://github.com/testing-library/user-event/blob/master/README.md) to
see the available APIs and feel free to propose new ones too.


Five Things You (Probably) Didn't Know About Testing Library


I continue my series of posts on `react-testing-library` this time with a brief
explanation on how to test asynchronous methods. The idea for this post comes
from a person who contacted me on Twitter asking this:

> [...] how would one test async methods loaded during `componentdidMount`?

In my personal experience 99% of the time an async method is going to fetch some
data from the server. This is especially true if we call this method from
`componentDidMount`. You can then understand how important it is to know how to
test these methods properly.

Two notes before I start:

- The question is about methods called in `componentDidMount` but the testing
  strategy is the same if you use Hooks;
- If you are uncertain how to make asynchronous calls in the first place check
  my other post
  [Fetching Asynchronous Data with React Hooks](../fetching-asynchronous-data-with-react-hooks).

---

There are two things you want to test when it comes to asynchronous methods. The
first is that the method itself got called and with the right parameters. The
second is that after the call your application responds as it should. Let's see
what this means in practice.

Imagine you have a small blog application written in React. In particular you
have an `Index` component that shows the list of posts—kinda like what I have in
[my homepage](/).

`Index` will probably look something like this:

```jsx
import React from "react";
import { fetchPosts } from "./api/posts";
import { useAsync } from "react-use";

function Index() {
  const posts = useAsync(fetchPosts, []);

  if (posts.loading) return "Loading...";
  if (posts.error) return "Something went wrong.";

  return (
    <>
      <h1>My Posts</h1>
      <ul>
        {posts.value.map((post) => (
          <li key={post.id}>
            <a href={post.url}>{post.title}</a>
          </li>
        ))}
      </ul>
    </>
  );
}
```

You have probably seen code like this before and maybe even written some
yourself. Here we're fetching a list of posts via the `fetchPosts` method. We're
showing a loading message while this happens. Once the async method resolves, we
either show an error or the list of posts.

If you are confused by the `useAsync` call refer to my
[previous post](../fetching-asynchronous-data-with-react-hooks) where I explain
how it works.

If you prefer to avoid Hooks, this is the class implementation (note that the
tests we're going to write are going to work with both implementations):

```jsx
import React from "react";
import { fetchPosts } from "./api/posts";

class Index extends React.Component {
  state = { loading: true, error: null, posts: null };

  async componentDidMount() {
    try {
      this.setState({ loading: true });
      const posts = await fetchPosts();
      this.setState({ loading: false, posts });
    } catch (error) {
      this.setState({ loading: false, error });
    }
  }

  render() {
    if (this.state.loading) return "Loading...";
    if (this.state.error) return "Something went wrong.";

    return (
      <>
        <h1>My Posts</h1>
        <ul>
          {this.state.posts.map((post) => (
            <li key={post.id}>
              <a href={post.url}>{post.title}</a>
            </li>
          ))}
        </ul>
      </>
    );
  }
}
```

A bit longer to type but it does the same thing the Hook version does.

Now to the tests!

---

The first thing we want to do is to mock the API calls. Why? I can give you two
good reasons for this. The first one is that it will make our tests more
reliable. If your test fetched the list of posts, it would need a server to
call. This server might or might not be working making our tests failing
randomly.

The second reason is speed. Performing a real API call takes time. It might not
seem like much when you have just one test but as your codebase grows the
slowness will show.

So, how do we mock the API call? In our case, the call happens in the
`fetchPosts` method so we can mock it:

```jsx
jest.mock("./api/posts");
```

You can read more about `jest.mock` in the
[official docs](https://jestjs.io/docs/en/jest-object#jestmockmodulename-factory-options).
What it does is to tell Jest to replace all the methods inside the `./api/posts`
module with a mock.

Now that we have the mock in place let's render the component and test that we
see a loading message:

```jsx
// highlight-start
import React from "react";
import { render, screen } from "@testing-library/react";
import Index from "./Index";
import "jest-dom/extend-expect";
// highlight-end

jest.mock("./api/posts");

// highlight-start
test("We show a list of posts", () => {
  render(<Index />);
  expect(screen.getByText("Loading...")).toBeInTheDocument();
});
// highlight-end
```

This was the first step. Now we need to make sure our async method gets called
correctly:

```jsx
import React from "react";
import { render, screen } from "@testing-library/react";
import Index from "./Index";
import "jest-dom/extend-expect";
import { fetchPosts } from "./api/posts"; // highlight-line

jest.mock("./api/posts");

test("We show a list of posts", () => {
  render(<Index />);
  expect(screen.getByText("Loading...")).toBeInTheDocument();
  // highlight-start
  expect(fetchPosts).toHaveBeenCalledTimes(1);
  expect(fetchPosts).toHaveBeenCalledWith();
  // highlight-end
});
```

We're testing that `fetchPosts` has been called once and with no arguments. Note
that, since we're using `jest.mock`, `fetchPosts` is not going to be the method
we have in our codebase but a
[mock function](https://jestjs.io/docs/en/mock-function-api).

OK, we're almost there. All is left to do is to return some data from
`fetchPosts` and verify it appears in the DOM. This is exactly what we're going
to do next:

```jsx
import React from "react";
import { render, screen, wait } from "@testing-library/react"; // highlight-line
import Index from "./Index";
import "jest-dom/extend-expect";
import { fetchPosts } from "./api/posts";

jest.mock("./api/posts");

// highlight-next-line
test("We show a list of posts", async () => {
  // highlight-start
  const posts = [{ id: 1, title: "My post", url: "/1" }];
  fetchPosts.mockResolvedValueOnce(posts);
  // highlight-end
  render(<Index />);
  expect(screen.getByText("Loading...")).toBeInTheDocument();
  expect(fetchPosts).toHaveBeenCalledTimes(1);
  expect(fetchPosts).toHaveBeenCalledWith();
  // highlight-start
  await wait(() => expect(screen.getByText("My Posts")).toBeInTheDocument());
  posts.forEach((post) =>
    expect(screen.getByText(post.title)).toBeInTheDocument()
  );
  // highlight-end
});
```

And that's it! We're returning some fake values using `mockResolvedValueOnce`.
We then wait for the async method to resolve and for `Index` to rerender. To do
that we use the `wait` method while checking that the title is rendered. After
that we go post-by-post and make sure the title is on the page.

---

If you wanted to test that errors are rendered correctly it's just a matter of
changing the mock:

```jsx
import React from "react";
import { render, screen, wait } from "@testing-library/react";
import Index from "./Index";
import "jest-dom/extend-expect";
import { fetchPosts } from "./api/posts";

jest.mock("./api/posts");

// highlight-next-line
test("We show an error message on failures", async () => {
  // highlight-start
  fetchPosts.mockRejectedValueOnce("Error!");
  // highlight-end
  render(<Index />);
  expect(screen.getByText("Loading...")).toBeInTheDocument();
  expect(fetchPosts).toHaveBeenCalledTimes(1);
  expect(fetchPosts).toHaveBeenCalledWith();
  // highlight-start
  await wait(() =>
    expect(screen.getByText("Something went wrong.")).toBeInTheDocument()
  );
  // highlight-end
});
```

---

To recap, these are the steps to test an asynchronous method:

1. Mock the method with
   [`jest.mock`](https://jestjs.io/docs/en/jest-object#jestmockmodulename-factory-options)
   and make it resolve to some data;
1. Test the loading state;
1. Test that the async method got called correctly;
1. Test that the component rendered the data correctly.


How to Test Asynchronous Methods with React Testing Library


I have been following the community around
[`react-testing-library`](https://testing-library.com/react) for a while now.
One of the questions that come up more often is how to test a custom select
component.

By _custom select_ I mean a component like
[`react-select`'s](https://react-select.com/home),
[Ant Design's](https://ant.design/components/select/) or
[Material-UI's](https://material-ui.com/api/select/).

<figure>
  <a href="https://material-ui.com/demos/selects/" target="_blank">
    <img src="/testing-a-custom-select-with-react-testing-library/selects.gif" title="Material-UI's select" />
  </a>
  <figcaption>Material-UI's select</figcaption>
</figure>

A large number of projects need a custom select. At first sight, they seem
simple components, but in reality, they are quite complex. They need to take
care of many use-cases and support accessibility features.

---

Suppose you wrote a new component that uses `react-select`:

```jsx
function MySelector() {
  const options = [
    { value: "red", label: "Red" },
    { value: "green", label: "Green" },
    { value: "blue", label: "Blue" },
  ];
  const [color, setColor] = React.useState(options[0]);

  return (
    <>
      <h1>Your favorite color is {color.label}</h1>
      <Select
        options={options}
        value={color}
        onChange={(value) => {
          console.log(value);
          setColor(value);
        }}
      />
    </>
  );
}
```

<figure>
  <img src="/testing-a-custom-select-with-react-testing-library/custom-select.gif" title="MySelector in action" />
  <figcaption><code>MySelector</code> in action</figcaption>
</figure>

Testing `MySelector` is not as easy at it seems:

```jsx
test("Naive test that doesn't work", () => {
  render(<MySelector />);
  expect(screen.getByText("Your favorite color is Red")).toBeInTheDocument();
  fireEvent.click(screen.getByText("Red"));
  fireEvent.click(screen.getByText("Green"));
  expect(screen.getByText("Your favorite color is Green")).toBeInTheDocument();
});
```

`react-select` is trying to be smart to give us the best user-experience
possible. However, all this extra logic makes testing harder.

You now have two options.

You can figure out what DOM structure `react-select` creates and then use
`container.querySelector` to find its elements and interact with them. It takes
a while, but it should be possible. After you have done all of that, you have to
hope that at every new release the `react-select` team doesn't change the DOM
structure too much or you might have to update all your tests.

The other option is to trust that `react-select` is going to make a component
that works and that your users can use. Based on that trust you can replace that
component in your tests for a simpler one.

In my experience, the second option works well and is much easier to maintain.

---

How do you replace the custom select for an easier one though? With
[`jest.mock`](https://jestjs.io/docs/en/jest-object#jestmockmodulename-factory-options).

In our case we want to replace `react-select` for a normal HTML `select` tag.
Here's how you can do it:

```jsx
// highlight-start
jest.mock("react-select", () => ({ options, value, onChange }) => {
  function handleChange(event) {
    const option = options.find(
      (option) => option.value === event.currentTarget.value
    );
    onChange(option);
  }

  return (
    <select data-testid="select" value={value} onChange={handleChange}>
      {options.map(({ label, value }) => (
        <option key={value} value={value}>
          {label}
        </option>
      ))}
    </select>
  );
});
// highlight-end

test("Test with mock", () => {
  render(<MySelector />);
  expect(screen.getByText("Your favorite color is Red")).toBeInTheDocument();
  // highlight-start
  fireEvent.change(screen.getByTestId("select"), {
    target: { value: "green" },
  });
  // highlight-end
  expect(screen.getByText("Your favorite color is Green")).toBeInTheDocument();
});
```

I've added a `data-testid` to make it easy to find the `select` and
implemented a `handleChange` handler that simulates the one from `react-select`.
Your logic might change depending on what custom select you are using but the
basic idea is the same.

You can find the full code for this example at
[Gpx/test-custom-select](https://github.com/Gpx/test-custom-select).


Testing a Custom Select with React Testing Library


I noticed several people getting confused on how to test React components that
rely on a context with `react-testing-library`. Before I even explain how to
test such components let me get something out of the way:

<p class="highlight">
There is no need to mock your contexts in order to test them.
</p>

[`jest.mock`](https://jestjs.io/docs/en/jest-object#jestmockmodulename-factory-options)
and friends are extremely helpful for many test scenarios, but context is not
one of them. So how do we go about testing it?

The answer is all in `react-testing-library`'s core principle:

https://twitter.com/kentcdodds/status/977018512689455106

What does <q>resemble the way your software is used</q> mean in our case? Let's
see a practical example:

```jsx
const UserContext = React.createContext();

function App() {
  const user = getUserOrMaybeNot();

  return (
    <UserContext.Provider value={user}>
      <UserGreeter />
    </UserContext.Provider>
  );
}

function UserGreeter() {
  const user = React.useContext(UserContext);

  if (!user) return "Hello stranger!";
  return `Hello ${user.name}!`;
}
```

In this particular case, `user` could or could not be defined depending on what
`getUserOrMaybeNot` returns.

You probably want to test that `UserGreeter` renders the correct thing in both
cases. You might be tempted to `render` `UserGreeter` and mock the context
somehow. That's not how your software is used though. Your component is rendered
within a provider. Let's do that then.

```jsx
test("UserGreeter salutes an anonymous user", () => {
  render(
    <UserContext.Provider value={null}>
      <UserGreeter />
    </UserContext.Provider>
  );
  expect(screen.getByText("Hello stranger!")).toBeInTheDocument();
});

test("UserGreeter salutes a user", () => {
  const user = { name: "Giorgio" };
  render(
    <UserContext.Provider value={user}>
      <UserGreeter />
    </UserContext.Provider>
  );
  expect(screen.getByText(`Hello ${user.name}!`)).toBeInTheDocument();
});
```

To avoid the repetition, you can move the render method in a helper function:

```jsx
function renderUserGreeter(user) {
  return render(
    <UserContext.Provider value={user}>
      <UserGreeter />
    </UserContext.Provider>
  );
}

test("UserGreeter salutes an anonymous user", () => {
  renderUserGreeter(null);
  expect(screen.getByText("Hello stranger!")).toBeInTheDocument();
});

test("UserGreeter salutes a user", () => {
  const user = { name: "Giorgio" };
  renderUserGreeter(user);
  expect(screen.getByText(`Hello ${user.name}!`)).toBeInTheDocument();
});
```

---

If you want more information about testing context with `react-testing-library`
check out the
[official docs](https://testing-library.com/docs/example-react-context) and join
the [spectrum community](https://spectrum.chat/react-testing-library) for help
getting you started.


Mocking Context with React Testing Library


<details class="tldr">
  <summary>TL;DR;</summary>

Use the
[`useAsync()`](https://github.com/streamich/react-use/blob/master/docs/useAsync.md)
hook from [streamich](https://github.com/streamich) to handle your asynchronous
needs.

</details>

Fetching data is one of those things that I do all the time in my code. I've
decided to take a look at ways to streamline it as much as possible.

## A Word About My Setup

Before we get started, there are a few things that might throw you off.

- I use `async`/`await`; you can read more about it
  [here](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function)
- I initialize my state with
  [class fields](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Classes#Field_declarations)
  rather than in the `constructor`
- In the examples, I'm going to call `getResource` which is a function that
  returns a
  [Promise](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise).
  I do this both because I want to hide the fetching logic and because it's then
  easier to test my component—I
  [`jest.mock`](https://jestjs.io/docs/en/jest-object#jestmockmodulename-factory-options)
  the import

## Fetch One Resource

Probably the most common use-case for asynchronous code is to fetch a single
resource when the component mounts. We need this all the time: fetch the latest
tweets for the user, get the list of friends, fetch the most popular
videos&hellip; the list goes on and on.

With class-based components we do this in the `componentDidMount` method:

```jsx
import React from "react";
import { getResource } from "./api";

class FetchOneResource extends React.Component {
  state = { valueA: null };

  async componentDidMount() {
    const valueA = await getResource("A");
    this.setState({ valueA });
  }

  render() {
    const { valueA } = this.state;

    return valueA == null ? "Loading..." : valueA;
  }
}
```

We fetch our resource and put the result in the state. Our `render` method uses
a
[ternary operator](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Conditional_Operator)
to decide if we want to show a loading message or our result.

The above code works but has two issues:

- What if `getResource()` fails?
- What if `getResource()` doesn't fail but returns `null`?

Those are usually considered _edge cases_ but they can happen. We can't push
this code in production unless we address these issues:

```jsx
import React from "react";
import { getResource } from "./api";

class FetchOneResource extends React.Component {
  state = {
    valueA: null,
    loadingA: true, // highlight-line
    errorA: null, // highlight-line
  };

  componentDidMount() {
    this.getA(); // highlight-line
  }

  // highlight-start
  async getA() {
    try {
      this.setState({ loadingA: true });
      const valueA = await getResource("A");
      this.setState({ valueA });
    } catch (e) {
      this.setState({ errorA: e });
    } finally {
      this.setState({ loadingA: false });
    }
  }
  // highlight-end

  render() {
    const { valueA, loadingA, errorA } = this.state; // highlight-line

    if (errorA) return "Failed to load resource A"; // highlight-line
    return loadingA ? "Loading..." : valueA; // highlight-line
  }
}
```

We added two new state variables, `loadingA` and `errorA`. Note how `loadingA`
is set to `true` initially. That's because we want to display the loading
message already at the first render.

We also moved the fetching in a separate method and wrapped it in a
`try`/`catch` statement. The
[`finally`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/try...catch#The_finally_clause)
branch is a somewhat new addition to JavaScript. It simply means "run this
branch all the time no matter if the above code failed or not."

---

Nowadays, I avoid writing React classes if I can help it. Let's see how we can
rewrite `FetchOneResource` using Hooks:

```jsx
import React, { useState, useEffect } from "react";
import { getResource } from "./api";

function FetchOneResource() {
  const [valueA, setValueA] = useState(null);
  const [errorA, setErrorA] = useState(null);
  const [loadingA, setLoadingA] = useState(true);
  async function getA() {
    try {
      setLoadingA(true);
      const valueA = await getResource("A");
      setValueA(valueA);
    } catch (e) {
      setErrorA(e);
    } finally {
      setLoadingA(false);
    }
  }
  useEffect(() => {
    getA();
  }, []);

  if (errorA) return "Failed to load resource A";
  return loadingA ? "Loading..." : valueA;
}
```

Most of the code remained the same, so let's focus on the differences.

We converted our class into a function. That's because Hooks can be used only
within a functional component.

Our state is now declared with the
[`useState`](https://reactjs.org/docs/hooks-reference.html#usestate) hook which
gives us back the value and a function to set it. This is roughly how it
compares to a class-based state:

```jsx
// This code in a class component...
this.setState({ foo: 42 });
console.log(this.state.foo);

// ...is equivalent to this code in a functional component
const [foo, setFoo] = useState();
setFoo(42);
console.log(foo);
```

The other Hook that we're using is
[`useEffect`](https://reactjs.org/docs/hooks-reference.html#useeffect). It's
probably the most complex of all pre-defined Hooks I wrote a bit about how it
works [here](/posts/making-sense-of-useeffect). In this case, we're using it to
run our `getA` function for us precisely one time after the component mounts.

---

Before we move on to the next example, I would like to take a minute to refactor
our component. The code as is written works fine but it's very verbose, I would
like to make it easier to follow.

One advantage of Hooks is that they are composable and make it easy to extract
logic in a separate function.

We can take advantage of this and move our code to fetch in a separate method:

```jsx
import React, { useState, useEffect } from "react";
import { getResource } from "./api";

function useA() {
  const [valueA, setValueA] = useState(null);
  const [errorA, setErrorA] = useState(null);
  const [loadingA, setLoadingA] = useState(true);
  async function getA() {
    try {
      setLoadingA(true);
      const valueA = await getResource("A");
      setValueA(setValueA);
    } catch (e) {
      setErrorA(e);
    } finally {
      setLoadingA(false);
    }
  }
  useEffect(() => {
    getA();
  }, []);

  return [valueA, errorA, loadingA]; // highlight-line
}

function FetchOneResource() {
  const [valueA, errorA, loadingA] = useA(); // highlight-line
  if (errorA) return "Failed to load resource A";
  return loadingA ? "Loading..." : valueA;
}
```

Ah! Much better, don't you think? Our `FetchOneResource` is now only three lines
long, and it's quite easy to understand what is going on.

Still, I think we can do better. But first, let's see how to fetch more than one
asynchronous resource at the same time.

## Fetch Multiple Resources at the Same Time

In many cases, you want to load more than one resource at the same time. Think
of a page that renders a list of posts and your followers.

Let's see how we could do it with Hooks. First a naive implementation:

```jsx
import React, { useState, useEffect } from "react";
import { getResource } from "./api";

function useA() {
  const [valueA, setValueA] = useState(null);
  const [errorA, errorA] = useState(null);
  const [loadingA, setLoadingA] = useState(true);
  async function getA() {
    try {
      setLoadingA(true);
      const valueA = await getResource("A");
      setValueA(valueA);
    } catch (e) {
      setErrorA(a);
    } finally {
      setLoadingA(false);
    }
  }
  useEffect(() => {
    getA();
  }, []);

  return [valueA, errorA, loadingA];
}

function useB() {
  const [valueB, setValueB] = useState(null);
  const [errorB, setErrorB] = useState(null);
  const [loadingB, setLoadingB] = useState(true);
  async function getB() {
    try {
      setLoadingB(true);
      const valueB = await getResource("B");
      setValueB(valueB);
    } catch (e) {
      setErrorB(a);
    } finally {
      setLoadingB(false);
    }
  }
  useEffect(() => {
    getB();
  }, []);

  return [valueB, errorB, loadingB];
}

function FetchMultipleResourceAtOnce() {
  const [valueA, errorA, loadingA] = useA();
  const [valueB, errorB, loadingB] = useB();

  return (
    <div>
      {errorA
        ? "Failed to load resource A"
        : loadingA
        ? "Loading A..."
        : valueA}
      {errorB
        ? "Failed to load resource B"
        : loadingB
        ? "Loading B..."
        : valueB}
    </div>
  );
}
```

We're duplicating a lot of code, but it's quite easy to fix it. `useA` and
`useB` are basically the same function. The only difference is that they are
passing different arguments to `getResource`. Let's fix that:

```jsx
import React, { useState, useEffect } from "react";
import { getResource } from "./api";

function useAsync(getMethod, params) {
  const [value, setValue] = useState(null);
  const [error, setError] = useState(null);
  const [loading, setLoading] = useState(true);
  async function getResource() {
    try {
      setLoading(true);
      const result = await getMethod(...params);
      setValue(result);
    } catch (e) {
      setError(e);
    } finally {
      setLoading(false);
    }
  }
  useEffect(() => {
    getResource();
  }, params);

  return { value, error, loading };
}

function FetchMultipleResourceAtOnce() {
  const resourceA = useAsync(getResource, ["A"]); // highlight-line
  const resourceB = useAsync(getResource, ["B"]); // highlight-line

  return (
    <div>
      {resourceA.error
        ? "Failed to load resource A"
        : resourceA.loading
        ? "Loading A..."
        : resourceA.value}
      {resourceB.error
        ? "Failed to load resource B"
        : resourceB.loading
        ? "Loading B..."
        : resourceB.value}
    </div>
  );
}
```

We made a generic `useAsync` Hook that takes two parameters: the method to call
and the list of parameters to call it with.

Note that we are now passing `params` to `useEffect` so that if one of them
changes we fetch the resource again.

We're also not returning an array anymore but an object. I think an object is
easier to handle because it creates only one variable and doesn't force us to
remember the order in which the results are returned.

The last thing left to do is to take `useAsync` and move it in a separate file
so that we can use it in other components too. Luckily a version of
`useResource` that works similarly to ours is available as part of
[react-use](https://github.com/streamich/react-use).

```jsx
import React from "react";
import { getResource } from "./api";
import { useAsync } from "react-use"; // highlight-line

function FetchMultipleResourceAtOnce() {
  const resourceA = useAsync(getResource, ["A"]);
  const resourceB = useAsync(getResource, ["B"]);

  return (
    <div>
      {resourceA.error
        ? "Failed to load resource A"
        : resourceA.loading
        ? "Loading A..."
        : resourceA.value}
      {resourceB.error
        ? "Failed to load resource B"
        : resourceB.loading
        ? "Loading B..."
        : resourceB.value}
    </div>
  );
}
```

---

You can find `useAsync` [here](https://github.com/streamich/react-use) in case
you want to use it in your projects. The actual implementation is a bit more
complex than the one presented in this post so make sure you check out the
[README](https://github.com/streamich/react-use/blob/master/docs/useAsync.md).


Fetching Asynchronous Data with React Hooks


During the past few weeks, I had the chance to introduce many of my colleagues
to React Hooks.

The overall feedback is that they are an improvement over class components. Code
written with Hooks looks more natural to follow and to reason about.

There is, however, one common complain whenever I explain the predefined Hooks:
`useEffect` is complicated to understand.

Indeed its API is not as straightforward as other Hooks, although once one
understands how it works, it is flexible and powerful.

In this post, I _do not_ want to explain how it works—for that you can check the
[official docs](https://reactjs.org/docs/hooks-effect.html). Instead, I want to
go through common patterns and see how to convert them from a class-based
implementation to one using `useEffect`.

## Do Something When the Component Mounts

This is possibly the most common pattern in class components. We do this all the
time, for example, to fetch some data.

Here's how it looks like in a class component:

```jsx
class MyComponent extends React.Component {
  state = { foo: null, bar: null };

  componentDidMount() {
    this.fetchFoo();
    this.fetchBar();
  }

  async fetchFoo() {
    const foo = await fetch("/foo").then((res) => res.json());
    this.setState({ foo });
  }

  async fetchBar() {
    const bar = await fetch("/bar").then((res) => res.json());
    this.setState({ bar });
  }

  render() {
    return (
      <div>
        {foo}, {bar}
      </div>
    );
  }
}
```

In this example we're simply fetching two values, `foo` and `bar`, when the
component mounts. If you are unfamiliar with `async`/`await` you can read more
about it
[here](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function).

The same code would look like this with React Hooks:

```jsx
function MyComponent() {
  const [foo, setFoo] = useState(null);
  const [bar, setBar] = useState(null);

  async function fetchFoo() {
    const foo = await fetch("/foo").then((res) => res.json());
    setFoo(foo);
  }

  async function fetchBar() {
    const bar = await fetch("/bar").then((res) => res.json());
    setBar(bar);
  }

  useEffect(() => {
    fetchFoo();
    fetchBar();
  }, []);

  return (
    <div>
      {foo}, {bar}
    </div>
  );
}
```

It's hopefully easy to see that there are several similarities between the two
implementations.

The important thing to notice is the second parameter we're passing to
`useEffect`: an empty array. We do this to tell `useEffect` to run only once.

Although the code works, it has a problem. We're grouping the code that deals
with `foo` with the one that handles `bar`. This is a necessity when we're
working with class components because we have to put all our logic within the
`componentDidMount` method.

With Hooks we can separate our code by concerns. Let's refactor the previous
example to see this idea in action:

```jsx
function MyComponent() {
  const [foo, setFoo] = useState(null);
  async function fetchFoo() {
    const foo = await fetch("/foo").then((res) => res.json());
    setFoo(foo);
  }
  useEffect(() => {
    fetchFoo();
  }, []);

  const [bar, setBar] = useState(null);
  async function fetchBar() {
    const bar = await fetch("/bar").then((res) => res.json());
    setBar(bar);
  }
  useEffect(() => {
    fetchBar();
  }, []);

  return (
    <div>
      {foo}, {bar}
    </div>
  );
}
```

We've reorganized the order of our declarations so that we end up with two
_visual blocks_. The first one about `foo` and the second about `bar`.

Note how we can call `useEffect` more than once.

## Do Something When the Component Unmounts

Most times after you set up some sort of listener when the component mounts you
have to unregister it if the component unmounts. Failing to do so might result
in memory leaks and other unintended behavior.

First, let's see the class version:

```jsx
class MyComponent extends React.Component {
  componentDidMount() {
    document.addEventListener("click", this.handleClick);
  }

  componentWillUnmount() {
    document.removeEventListener("click", this.handleClick);
  }

  handlClick() {
    console.log("Clicked!");
  }

  render() {
    return <div />;
  }
}
```

With `useEffect` you can do the same by returning a function:

```jsx
function MyComponent() {
  function handlClick() {
    console.log("Clicked!");
  }
  useEffect(() => {
    document.addEventListener("click", handleClick);

    // highlight-start
    return () => {
      document.removeEventListener("click", handleClick);
    };
    // highlight-end
  }, []);

  return <div />;
}
```

## Do Something When One or More Props Change

Our last example is about reacting to prop changes. With a class you would have
to use `componentDidUpdate`:

```jsx
class MyComponent extends React.Component {
  state = { user: null };

  async componentDidMount() {
    this.fetchUser();
  }

  componentDidUpdate(prevProps) {
    if (prevProps.userId !== this.props.userId) {
      // We have to fetch the user again
      this.fetchUser();
    }
  }

  async fetchUser() {
    user = await getUser(this.props.userId);
    this.setState({ user });
  }

  render() {
    return user && user.name;
  }
}
```

With `useEffect` we can pass `userId` in the list of parameters to watch:

```jsx
function MyComponent(props) {
  const [user, setUser] = useState(null);
  async function fetchUser() {
    user = await getUser(props.userId);
    setUser(user);
  }
  useEffect(() => {
    fetchUser();
  }, [props.userId]);

  return user && user.name;
}
```

You can pass as many values as you want in the array. They don't necessarily
have to be props, in fact they can come from anywhere.


Making Sense of <code>useEffect</code>


Before Hooks were introduced in React I used to create "null&nbsp;components".
In other words components that render nothing. One example of such component is
the following:

```jsx
class PageTitle extends React.Component {
  componentDidMount() {
    document.title = this.props.title;
  }

  componentDidUpdate() {
    document.title = this.props.title;
  }

  render() {
    return null;
  }
}
```

This component renders nothing at all. Its only use is to change the page title.

With Hooks it could be rewritten to something like this:

```jsx
function PageTitle(props) {
  useEffect(() => {
    document.title = props.title;
  }, [props.title]);
  return null;
}
```

I think null components should all become Hooks instead. It's easy to see why.
If we remove the `return` statement and rename `PageTitle` to `usePageTitle` we
have our Hook:

```jsx
function usePageTitle(title) {
  useEffect(() => {
    document.title = title;
  }, [title]);
}
```

If `PageTitle` and `useTitle` are so similar what's the advantage of using the
Hook version?

When I use a component I generally expect something to appear on the page. With
Hooks I expect the opposite. So, converting `PageTitle` to `usePageTitle` makes
it obvious to any developer who's using my code that nothing will be rendered on
the page.

<p class="highlight">
Here's the rule of thumb: is your component always rendering nothing?
Convert it to a Hook.
</p>


Null Components Should be Hooks


Last Sunday, October 21st, I took part in
<a href="https://hacktoberfestbarcelona.com/" target="_blank">Hacktoberfest
Barcelona</a>. If you don't know what it is, Hacktoberfest is an initiative by
DigitalOcean, GitHub and Twilio. It encourages people to contribute to
open-source projects for the whole month of October.

In our Barcelona chapter, we focused on helping newcomers starting contributing
from day one. We had presentations and hands-on exercises.

Among all of this, I wrote a short document to help people getting started.
Following is that document adapted for Medium. I hope others will find it
useful.

---

Imagine it's your first day at a new job. Your company has quite a few
developers already, and they're working on a cool internal project. Everyone
there knows you're staring today. They give you your new laptop, hook you up
with all the accounts you need, they show you how the coffee machine works and
then you can start. You install all the tools, make sure the project is working
on your machine (usually it doesn't) and then they have a task for you.

They prepared this task just for you because it's your first day. This task will
help you understand the project and start contributing. Usually, it's some
refactoring. You start working on it and maybe you finish it in one day, maybe
it’ll take longer.

Open source is more or less like starting at a new job only nobody knows that
you’re coming and they didn't prepare anything for you. You have to go and
decide what to work on.

This is just to say that it's not easy to get started and if you manage to open
only one pull request today consider it a success. But trust us if you keep at
it it'll get easier and you'll get better.

Beginnings are hard and everybody has to start somewhere. Don't feel discouraged
if you've never done any open source before, we've all been beginners. At
<a href="https://firstpr.me/" target="_blank">firstpr.me</a> you can see what
was the first PR for any GitHub user. Maybe you can get some inspiration out of
it. A few examples:

- <a href="https://firstpr.me/#jeresig" target="_blank">John Resig</a> creator
  of jQuery, he wrote several books on JavaScript
- <a href="https://firstpr.me/#sdras" target="_blank">Sarah Drasner</a> Vue core
  team member and O'Reilly published author
- <a href="https://firstpr.me/#kentcdodds" target="_blank">Kent C. Dodds</a>
  react-testing-library creator. Works at Paypal and he's part of TC39
- <a href="https://firstpr.me/#peggyrayzis" target="_blank">Peggy Rayzis</a>
  engineering manager Apollo and speaker
- <a href="https://firstpr.me/#jordwalke" target="_blank">Jordan Walke</a>
  creator of React
- <a href="https://firstpr.me/#stubbornella" target="_blank">Nicole Sullivan</a>
  Google Chrome project manager
- <a href="https://firstpr.me/#wycats" target="_blank">Yehuda Katz</a>
  co-creator of Ember, Rust/Ruby on Rails/jQuery Core Team, TC39 member
- <a href="https://firstpr.me/#eveporcello" target="_blank">Eve Porcello</a>
  JavaScript teacher and O'Reilly published author
- <a href="https://firstpr.me/#mhevery" target="_blank">Miško Hevery</a> creator
  of Angular. Funny enough, it looks like the core developers of Angular opened
  Github just to work on their framework
- <a href="https://firstpr.me/#flarnie" target="_blank">Flarnie Marchan</a>
  Facebook Software Engineer, React Core Team
- <a href="https://firstpr.me/#staltz" target="_blank">André Staltz</a> creator
  of Cycle.js
- <a href="https://firstpr.me/#LeaVerou" target="_blank">Lea Verou</a> W3C CSS
  Working Group invited expert. Her PR is from 2013 and is yet to be merged :)

The list goes on. Try it out with some of the developers you follow to see how
they started.

If you have no idea how to open a pull request or even what git is no worries.
We've all been in your shoes at some point. If you want to understand a bit
better how this whole pull request thing works check out this great
<a href="https://egghead.io/courses/how-to-contribute-to-an-open-source-project-on-github" target="_blank">Egghead
course</a>.

## Work on Documentation

Now, look back at the first PRs from famous developers. One common theme you can
see is that most of those are about fixing typos or improving a documentation.
That's a great way to start. Coding can take some effort but _veryone know how
to fxi a borken sntence_.

So, here's idea #1 if you want to start contributing:

<p class="highlight">
 Pick a project you're interested in and start reading its documentation. Did
 you find a typo? Open a PR. Is there a passage that is not clear or could use
 some rewording? Open a PR. Do you think one more example could make the idea
 easier to understand? Open a PR. Does it have a multi-language documentation
 but the one in your mother tongue is missing? Open a&hellip; well you get the idea.
</p>

You will not only contribute to the project but at the same time learn a new
tool by reading its docs. Win-win!

And please please PLEASE do not think this is a minor task. Documentation is one
of the most important parts of any project. And I'm not just saying that. Most
projects die because of a lack of good documentation. If you help in this area
the maintainers will be grateful.

## Find a Project

Ok, writing documentation is great and all but you want to write some code. The
best way to start is to pick a tool you already use. Why? Because you know how
it works and you know what it should and should not do. Do you follow its Github
repo? You should, many ideas come out from there. Check open issues and PRs to
see if there's something you could help with. What are people saying on
<a href="https://stackoverflow.com/" target="_blank">Stack Overflow</a> about
it? Are they confused about something? Sometimes a question could lead to
improving the documentation or refactoring some part of the code to make it
easier to work with.

One piece of advice here.

<p class="highlight">
Try to start with small projects with not too many contributors.
</p>

A big repo like Angular's will take a long time just to start up and usually,
when a new problem comes up, there's a dozen or so of developers ready to fix
it. Bottom line: start small.

Still don't know what to work on?
<a href="https://up-for-grabs.net/#/" target="_blank">Up For Grabs</a> has a
list of projects that are looking for help. Check out if there's something that
could be interesting for you. Other great sources are
<a href="https://github.com/search?utf8=%E2%9C%93&q=label%3Afirst-timers-only+is%3Aopen&type=Issues&ref=searchresults" target="_blank">first-timers-only</a>
and
<a href="https://github.com/MunGell/awesome-for-beginners" target="_blank">awesome-for-beginners</a>.
These are all projects that have decided to mark some of their issues for first
timers. When you find an issue you want to work on claim it. That means comment
in the issue page that you're going to work on it. This is to avoid having more
than one person fixing the same problem.

---

One important thing, no matter what you end up doing. Be nice and be kind.
Behind every Github user there's a real person. Maintainers have other things to
do. They have families, friends, hobbies and often another job. If somebody
doesn't reply immediately, or if they just close your PR with an abrupt comment
don't take it personally. They probably have other 200 PRs to go through.


How to Start with Open Source


Recently at
<a href="https://www.travelperk.com/" target="_blank">TravelPerk</a>, we've been
working hard to allow our users to access our platform when they're on the go.
Developing web applications for mobile devices brings a new set of problems that
are not always easy to solve.

More specifically, a problem we recently encountered was severely affecting the
performance of one of our pages.

Without going into too much into details, we discovered that the culprit was a
method similar to the one below:

```js
function parseObject(result) {
  return {
    computedValue: superSlowMethod(result.parameter),
    /* Plus some other props */
  };
}
```

As you may have guessed already, `superSlowMethod` was&hellip; well super slow.
If that were not enough, we were calling `parseObject` thousands of times since
we had to parse many objects.

We tried our best to speed up `superSlowMethod`, but we could not find any way
to make it fast enough.

What we noticed though is that we were only reading `computedValue` for less
than a dozen objects. We decided to find a way to calculate `computedValue` only
when strictly necessary.

A first idea was to not define `computedValue` at all and instead call
`superSlowMethod` only where it is needed. In a nutshell, do the following:

```js
// Instead of doing this
console.log("The value is: " + parsedObject.computedValue);

// We would do this
console.log("The value is: " + superSlowMethod(parsedObject.parameter));
```

Although this approach would have worked it had three issues for us:

1. It forces to substitute every instance of `computedValue` for a function
   call. Our codebase is quite big, and this is not an easy task.
1. It would make accessing `computedValue` different from all the other
   properties defined in the object.
1. If the code is executed more than once the value gets recalculated again,
   even though it did not change.

## Lazy Evaluation

What we decided to do is to apply a concept called _lazy evaluation_. In a
nutshell, lazy evaluation means to evaluate an expression only when it's needed.

For a simple example consider this code:

```js
a() && b();
```

JavaScript first evaluates `a()`, if it's `false` it will not evaluate `b()`
because its value is not needed. In this case, we can say that `b()` is lazily
evaluated.

Obviously, avoiding the need to evaluate an expression makes our program run
faster.

---

Coming back to our example we could not use a logic operator like `&&` to lazy
evaluate. Instead we used
<a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/defineProperty" target="_blank">`Object.defineProperty`</a>.

As the name already indicates this method allows us to define a property on an
object. It's different from doing `obj.newProperty = value` because it allows to
set some useful options. In our case we used the `get` method:

```js
function parseObject(result) {
  const parsedObject = {
    /* Plus some other props */
  }
  Object.defineProperty(parsedObject, 'computedValue', {
    get() {
      return superSlowMethod(this.parameter)
    }
  })

  reutrn parsedObject
}
```

With this small change, we are still able to access `parsedObject.computedValue`
like before but its value is calculated at the moment.

## Memoization

Our code was now running faster, but there was yet another technique we could
use: _memoization_.

Memoization means to execute a method, save its output and return it for future
invocations.

In our case, since `parameter` was never changing it made sense to apply
memoization:

```js
function parseObject(result) {
  const parsedObject = {
    /* Plus some other props */
  }
  let computedValue = null
  Object.defineProperty(parsedObject, 'computedValue', {
    get() {
      if (computedValue) return computedValue
      computedValue = superSlowMethod(this.parameter)
      return computedValue
    }
  })

  reutrn parsedObject
}
```

And with that, we went from calculating `computedValue` thousand of times to
just a handful of occasions.


Optimizing JavaScript with Lazy Evaluation and Memoization


As you probably know, JavaScript was created by
[Brendan Eich](https://twitter.com/BrendanEich) in 1995 in only ten days. Many
developers love to make fun of it, but it's an excellent language if you
consider how little designing it took. Most of us can't event finish a sprint in
ten days, let alone implement a programming language.

Of course, it's far from perfect and through they years it got updated, although
not as much as it should have. Luckily TC39, the committee responsible for
evolving the language, decided to release one new version every year starting
from 2016.

We already saw the first benefits of this work with ES6. All the new features
(arrow functions, generators, modules, &hellip;) make it almost look like a new
language.

Despite all these efforts, JavaScript still falls behind if compared to other
programming languages and will have a very hard time catching up. There's no
support for data types, it's difficult to work with double precision numbers, we
need to use libraries like
<a href="https://lodash.com/" target="_blank">Lodash<a> or
<a href="https://momentjs.com/" target="_blank">Moment</a> to have a decent
standard library. It's functional but pales if compared to other languages like
<a href="https://www.haskell.org/" target="_blank">Haskell</a> or
<a href="https://elixir-lang.org/" target="_blank">Elixir</a>.

The list goes on and on. After all, its initial purpose was to allow creating
basic interactive pages far from what we are building today.

What's making improvements to the language so slow is the fact that JavaScript
is always retro-compatible. Every new change must not break existing code. There
are more than one billion websites out there, and all of them must still work
after every browser update.

<p class="highlight">
We need a new language. A language that is better suited to help us create the web of tomorrow. The problem is that browsers won't get one anytime soon.
<p>

The one language that got closest to being adopted by browsers was Dart. When
Google released it, people were afraid it was part of a secret plan to
substitute JavaScript in Chrome. Needless to say, this never happened.

Even if all browser vendors decided to switch from JavaScript to a new language,
developers would still have to support older browsers. In other words, we would
have to build two versions of the same application. Remember when we had to
create a mobile version for websites or add specific CSS code for one browser?
This would be 1000 times more painful.

---

So why am I saying that I won't be coding in JavaScript in 5 years? Rest assured
it's not because I decided to become a native developer. Nothing against native
development but I love the web, and I hope I'll keep creating web applications
for many years to come.

I attended <a href="https://twitter.com/jhusain" target="_blank">Jafar
Husain</a>’s talk at the last
<a href="https://2016.fullstackfest.com/" target="_blank">Full Stack Fest</a> in
Barcelona. His talk was about
<a href="https://2016.fullstackfest.com/speakers/jafar-husain/" target="_blank">the
future of ES6</a> and, in particular, new ways to handle asynchronous code.

During the Q/A I asked this question:

<blockquote class="twitter-tweet"><p lang="en" dir="ltr">nope.</p>&mdash; Jafar Husain (@jhusain) <a href="https://twitter.com/jhusain/status/773834257055776768?ref_src=twsrc%5Etfw">September 8, 2016</a></blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"></script>

He also gave a
<a href="https://youtu.be/3pKNRgResq0?t=30m47s" target="_blank">longer
answer</a> on stage. He claims we should be happy to use tools like Babel. They
allow us to use the latest features of JavaScript today without having to wait
for browser vendors to implement them.

He also added that, since we have source maps, we don't even have to deal with
the transpiled code anymore.

In 5 years JavaScript will look very different from what we have now. Still,
that code will be transpiled to ES6 or even 5.

<p class="highlight">
  And that got me thinking: if I must use a transpiler anyway, why not choosing
  one that works with a better language? A language built to create rich web applications.
</p>

You may argue that since we transpile to JavaScript, this new language could not
be too much different and would be bound to JavaScript's internal logic. It
would just be some syntactic sugar on top of it. Similar to
<a href="https://www.typescriptlang.org/" target="_blank">TypeScript</a> or
<a hrerf="https://facebook.github.io/jsx/" target="_blank">JSX</a>.

Well, I’m happy to tell you that we're already working on a low-level format,
and it is called
<a href="https://webassembly.org/" target="_blank">WebAssembly</a>. It's not
ready yet, but when it will be, new languages will flourish. These languages
will be compiled and executed by the browser almost as fast as native code. And
they won't have to be retro-compatible because developers will compile them, the
source code won't be sent to the client.

Think of what assembly is to C but built for the web.

So, I don't know which programming language I will be using in 5 years. Elm is
currently the top candidate, and it
<a href="https://elm-lang.org/blog/farewell-to-frp#what-is-next-" target="_blank">expressed
intent</a> to support WebAssembly at some point. What I can tell you is that in
the future instead of having a new front-end framework every week we’ll have new
front-end languages. And that, if you ask me, is a good thing.


Why We Won't Be Writing JavaScript in Five Years


Yesterday I gave my first tech talk at the
[ReactJS Barcelona](www.meetup.com/ReactJS-Barcelona/events/232564030/) meetup.
I have to say that I really enjoyed the experience and I hope I’ll do it again
in the future.

My talk was about [CSS Modules](https://github.com/css-modules/css-modules) and
how to use them with a [React](https://facebook.github.io/react/) application.

You can find the slides
[here](https://speakerdeck.com/gpx/css-modules-and-react).

<iframe width="560" height="315" src="https://www.youtube.com/embed/01akERV571o?start=1322" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>


CSS Modules & React


Around seven years ago (gosh I’m getting old), I started to work on my first
serious single page application. I was the only frontend developer. A friend of
mine was working on the backend. Before that, I worked only on small jQuery
snippets. Things like “make this button disappear when I click on it”. I didn’t
study JavaScript, I didn’t feel the need to. After all, I knew Java.

It goes without saying, the project was a mess. A real example of spaghetti
code. It was so complicated to understand what was going on that I had to create
a set and a get method. They were two **sync** AJAX calls that were saving a
variable in `$_SESSION` and getting it back. All because I couldn’t figure out a
way to access values from different sections of my codebase.

After this terrible experience, I realized JavaScript might not be just a light
version of Java. I started _googling_ for some good material for a beginner like
me. Almost everyone’s advice was to read
[“Javascript: The Good Parts”](http://shop.oreilly.com/product/9780596517748.do).
The author, [Douglas Crockford](https://www.crockford.com), remained ever since
a guru for me. He often says:

> If a feature is sometimes useful and sometimes dangerous, and if there is a
> better option then, always use the better option.

You can see this motto applied to his code, his style is unambiguous and easy to
follow, although it may appear verbose.

What does this have to do with _function composition_ you might ask. Fast
forward to one year ago. I saw this talk from Douglas about “The Better Parts”.

<iframe width="560" height="315" src="https://www.youtube.com/embed/bo36MrBfTk4" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

With ES6 coming he decided to give an update on what are the new “good parts”. I
was very much into `class` back then, like many others, so I couldn’t wait to
hear my guru explain how and why they’re so cool.

With my great surprise they weren’t in the list. He mentioned things like
[tail call optimization](../es6-tail-call-optimization) and
[spread](https://github.com/lukehoban/es6features#default--rest--spread) but not
classes.

He eventually talked about the class keyword, it was the first of the new _bad
features_.

## A Crazy Little Thing Called Functional Programming

That talk left me puzzled. Not only he wasn’t using classes, he wasn’t using
`this`, `new`, `for` loops and pretty much what was 80% of my code. He was even
[freezing objects](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/freeze)
after creating them.

What’s the deal Doug? Why are you trying to make my life a hell? Are you just
mocking me? Are you mocking us all? It was a prank talk, wasn’t it? The guru
decided to have some fun at the expense of his followers.

Turns out it wasn’t a prank.

While in university, I attended a course about functional programming. The mood
was this:

> There’s a programming language called
> [Lisp](<https://en.wikipedia.org/wiki/Lisp_(programming_language)>). We use it
> in academia but in the real world no one does. You’re going to learn enough of
> it to build a small program and pass the exam.

Damn I hated school.

Lisp may not be in much use nowadays, but it influenced languages that are
taking the world by storm, such as [Clojure](http://clojure.org/) and
[Haskell](https://www.haskell.org/).

Most importantly, its functional paradigm is going to be more and more
predominant in the foreseeable future.

Oh and by the way, do you know what’s the most popular functional language by a
vast margin? JavaScript.

All this just to tell you that we better learn function composition and other
functional idioms.

## Finally Some Function Composition

After my longest introduction yet, let’s get into function composition. First
off, function composition works at its best when we _curry_ a function. What’s
that? Glad you asked.

### Currying

[Haskell Curry](https://en.wikipedia.org/wiki/Haskell_Curry) was a great
mathematician. So great that they named a programming language after his first
name and a programming technique after his last name (sadly nothing yet on his
middle name “Brooks”).

Let’s say you have a function sum that takes two parameters a and b and returns
their sum.

```jsx
const sum = (a, b) => a + b;

sum(1, 2); //=> 3
```

If the code above looks weird to you it’s because we’re using ES6, in particular
[constants](http://es6-features.org/#Constants) and
[arrow functions](http://es6-features.org/#ExpressionBodies).

In ES5, this would translate to:

```js
var sum = function (a, b) {
  return a + b;
};
```

When we call sum we have to provide 2 arguments. We also have to provide them at
the same time. What if I want to set a now and b later?

Basically, what we want is this:

```js
let partial = currySum(1);

partial(2); //=> 3

currySum(5)(5); //=> 10
```

How is this new `currySum` defined? This is one way to do it:

```js
const currySum = (a) => (b) => a + b;
```

`currySum` is a function that takes one argument a and returns a function. The
returned function accepts an argument `b` and returns `a + b`. This is possible
thanks to
[closures](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures).

How is this useful? Take our `partial` function, it could be renamed to `plus1`.
It is in fact a function that takes a number and adds 1 to it. We can easily
define `plus2` or `plus10`.

```js
const plus2 = currySum(2);
const plus10 = currySum(10);
```

Note that we can also convert a function to its curried version. Libraries like
[lodash](https://lodash.com/) implement a curry method. We are going to use
[Ramda](http://ramdajs.com/). Let’s see it in action.

```js
const sum = (a, b) => a + b;

const currySum = R.curry(sum);

currySum(3)(2); //=> 5
currySum(3, 2); //=> 5
```

As you can see `R.curry` takes a function and returns its curried version. The
nice thing is that we can then call the function passing all the arguments or
just some.

### Function Composition

Suppose you have this array:

```js
const colleagues = [
  {
    name: "Marek",
    developer: true,
  },
  {
    name: "Tim",
    developer: true,
  },
  {
    name: "Jan",
    developer: false,
  },
];
```

Now, you want a list of uppercased names.

```js
const names = [];
for (let i = 0; colleagues.length < i; i++) {
  names.push(colleagues[i].name.toUpperCase());
}

names; //=> ['MAREK','TIM','JAN']
```

Can we do better?

Let’s divide the problem. First we need a function that takes a string and
returns its uppercased version.

```js
const toUpper = (s) => s.toUpperCase();

toUpper("hello"); //=> 'HELLO'
```

Next we need a function that takes an object and returns one of its properties.

```js
const prop = (key, obj) => obj[key];

prop("name", { name: "Giorgio" }); //=> 'Giorgio'
```

We’re interested in the `name` property. What we need is a function that given
an object returns it’s `name`. If we curry our `prop` function that’s very easy.

```js
const prop = R.curry((key, obj) => obj[key]);

const getName = prop("name");
```

Wow, look at that. We called `prop` with just one argument and we got back
another function that receives an object and returns this object’s `name`
property. Now you begin to see why curring is so important.

Before we move on, you need to know that Ramda implements the two functions we
just defined. Furthermore Ramda functions are curried by default. So we can
refactor our code like this.

```js
const toUpper = R.toUpper;
const getName = R.prop("name");
```

Here comes the interesting part, given an object we want to get its `name`
property and uppercase it. One naïve solution is this.

```js
const upperName = (obj) => obj.name.toUpperCase();

upperName({ name: "Giorgio" }); //=> 'GIORGIO'
```

But this function is solving two problems we already solved:

- Getting the name property
- Uppercase a string

How can we do this using our pre-defined functions?

```js
const upperName = (obj) => toUpper(getName(obj));
```

Amazing, we composed the functions. We can now look at the official definition
for function composition (obviously from Wikipedia):

> In mathematics, function composition is the pointwise application of one
> function to the result of another to produce a third function.

This is exactly what we did. We took the output of `getName` and used it as an
input for `toUpper`.

Ramda has a `compose` function just for that. We can use it to refactor our
code.

```js
const upperName = R.compose(toUpper, getName);

upperName({ name: "Giorgio" }); //=> 'GIORGIO'
```

You should read the code from right to left. An object enters, it gets processed
by `getName`, you get a string and feed it to `toUpper`, you get a result.

Now to get the list of uppercased names from our objects we simply use `map`.

```js
const upperNames = R.map(upperName);

upperNames(colleagues); //=> ['MAREK','TIM','JAN']
```

Here is the whole code. I also made a
[pen](http://codepen.io/Gpx/pen/YybPGV?editors=001).

```js
const colleagues = [
  {
    name: "Marek",
    developer: true,
  },
  {
    name: "Tim",
    developer: true,
  },
  {
    name: "Jan",
    developer: false,
  },
];

const getName = R.prop("name");
const toUpper = R.toUpper;

const upperName = R.compose(toUpper, getName);

const upperNames = R.map(upperName);

const names = upperNames(colleagues); //=> ['MAREK','TIM','JAN']
```

## Is It worth It?

If you are like me you are probably asking yourself “Is it worth it?”. After all
the original code with a `for` loop was easy enough. The solution with function
composition works but it may seem a bit awkward. Let me tell you two big
advantages of our functional version.

The code has a higher level of abstraction. You have a `upperName` function.
What does it do? It applies `getName` and `toUpper`. No need to know about
arrays or indexes.

It’s much easier to extend. Want to upper the name only for developers?

```js
// Takes an array and filter out non-developers
const onlyDevelopers = R.filter(R.prop("developer"));

// Takes an array returns an array of uppercased names
// only for developers
const upperDevelopers = R.compose(upperNames, onlyDevelopers);

upperDevelopers(colleagues); //=> ['MAREK','TIM']
```

Here we solved the issue with another function composition.


JavaScript Function Composition


The web has been in great ferment in the last few years. HTML 5, ECMAScript 2015
and all the new landing features are making our beloved platform a great place
to be.

One of the most significant improvements is HTTP/2.

The _Hypertext Transfer Protocol_ evolved a lot since its beginnings in 1989.
When Tim Berners-Lee and his team created the protocol, they needed only a few
features.

This first version was simple: it allowed only to perform GET requests and
receive HTML data. Over the years, the [HTTP WG](https://httpwg.github.io/)
documented and updated the protocol bringing it to version 1.1.

Although most of the web runs on HTTP/1.1, this version has many issues.
Updating a protocol, especially if highly adopted, is not an easy task. For this
reason, developers had to create workarounds to many problems.

If you are a web developer you know most of them and chances are you’re using
them in your projects.

All those best practices are helpful but become counterproductive when used
alongside with HTTP/2. Let’s analyze them and see why is this the case.

## Domain Sharding

When we start an HTTP/1.x request, a new TCP connection is created. Once the
request ends, we can reutilize the connection so we don’t have to create a new
one.

This mechanism was serving us well during the early web but, with the time, we
outgrew it. A web page is no longer one single HTML file; we require CSS,
JavaScript and images.

For this reason, browsers started handling a connection pool of TCP streams.
Modern browsers usually support six streams per host. This means that, if your
page requires six images, the browser can download them in parallel. As you can
imagine, it is a great performance boost.

Even so, with the average web page asking for 90+ resources, this is still not
enough. Many requests will wait in queue before getting served.

Developers created a workaround to this problem: _domain sharding_. If a
browsers’ limit is six TCP connections per host, we can put our assets on
different hosts. That is, if our domain is _example.com_, images can be hosted
at _images.example.com_ and CSS files at _css.example.com_. In this way the
browser will open six parallel connections for your images and six for your CSS
files. Note that usually these subdomains are just CNAME DNS records that point
to the same IP address.

The browser will have to resolve each DNS name but you get a good performance
boost.

_If you decide to upgrade to HTTP/2 you should disable domain sharding._

HTTP/2 creates only one TCP connection and uses it to the fullest extent. The
stream can provide full [multiplex](https://en.wikipedia.org/wiki/Multiplexing)
support, both while sending and receiving. For this reason, clients no longer
need to initiate more TCP connections at the same time. However, if we host our
assets on different domains, the browser will have to create a new TCP
connection. This not only means more DNS requests. With HTTP/2 headers are sent
only when we first set them and when we want to change them, saving precious
bytes. Connecting to more than one host means sending the headers more than
once. Last, the client can prioritize the requests to receive the most important
data first. If we use domain sharding this option is less effective.

## Concatenation and Spriting

When you make a HTTP request you wait, at a minimum, for a full roundtrip of
latency before you get the first data back. For the average webpage this means a
lot of extra loading time. One obvious piece of advice here is “Don’t make a
request unless you need it”. Another way to speed-up the loading process is to
join together the resources you need.

When you join text files, usually JavaScript and CSS, we say we concatenate
them.

On the other hand, for images, we generate an _image sprite_. That is, an image
that contains more images. Using CSS we can then display only the part of the
image we need.

Both techniques allow us to generate less requests. Instead of 20 separate CSS
files we load just one that contains all others.

There are also downsides. Your page may not need all the data you concatenate
resulting in a waste of bandwidth. Also, if one of your assets changes, you
force the user to invalidate the cache and download it again. Last, your
JavaScript and CSS files will not get executed until the browser has finished to
downloading them.

All in all, for many applications running over HTTP/1.x, concatenation and
spriting is a good solution.

However, this is not true for HTTP/2, since many small resources can be
downloaded in parallel. In this case, the downsides of concatenating exceed its
benefits.

Another feature in HTTP/2 is the ability for the server to push data to the
client. When this happens, the browser will simply store the data in its cache.
Later, when that resource is needed, it can be fetched from the cache. This
makes concatenating even less necessary. We can instruct the server to push all
these little assets, giving them priority.

## Conclusions

HTTP/2
[is currently supported by most web browsers](http://caniuse.com/#feat=http2).
Although a decade will pass before the majority of the web upgrades to it. Even
so, you should plan your upgrade path now. The benefits you’ll get from it are
definitely worth it. Just remeber to question all the best practices you learned
through the years.


Mind the Gap when upgrading to HTTP/2


ECMAScript 6 a.k.a. ECMAScript 2015 a.k.a. the new version of JavaScript is
getting closer and closer to ratification, the current goal is to have the new
standard ready in June 2015. This is a big step forward for JavaScript that is
becoming a modern language, suitable for all the uses we need.

If you follow tech news you know about some of these changes:
[classes](http://es6-features.org/#ClassDefinition),
[modules](http://es6-features.org/#SymbolExportImport),
[spread operators](http://es6-features.org/#SpreadOperator)… In this post I will
analyze one less known feature: tail call optimization.

## CS 101: The Stack Frame

Let’s analyze this simple snippet of code:

```js
function foo() {
  console.log("foo");
  bar();
  console.log("bar called");
}

function bar() {
  console.log("bar");
  baz();
  console.log("baz called");
}

function baz() {
  console.log("baz");
  console.log("all done");
}

foo();
```

When we invoke `foo`, a new stack frame is created in memory. A stack frame is
simply a portion of memory where we store some values necessary to execute the
function, for instance local variables, arguments and most importantly the
caller of the function, so when the execution is done the _callee_ can return to
it.

Let’s see this in action using
[Chrome’s debugger](https://developer.chrome.com/devtools/docs/javascript-debugging):

![](/es6-tail-call-optimization/debug1.png)

In the orange rectangle, you have the stack frame and also a list of local
variables. It’s not exciting but let’s see what happens when we call `foo`:

![](/es6-tail-call-optimization/debug2.png)

A new stack frame gets created. Notice that the other frame is still there, we
will need it later. After `foo` calls `bar` that calls `baz`, we are in this
situation:

![](/es6-tail-call-optimization/debug3.png)

Two new stacks are created, one for `bar` and one for `baz`, those stacks are
listed in what is called call stack. The call stack is very useful when you
debug because it tells you the history of your program: which function called
which other function. After `baz` has done its job it returns back to `bar`:

![](/es6-tail-call-optimization/debug4.png)

As you can see, the stack frame for `baz` is deleted because we no longer need
it anymore. Every time a function returns, its stack frame gets deleted. After
our program is done, the call stack will be empty:

![](/es6-tail-call-optimization/debug5.png)

## Maximum Call Stack Size

Now that you have a general understanding of what stack frame and call stack
are, we can see an error you may encounter while programming.

Imagine you have this function:

```js
function foo(n) {
  if (n === 0) return;
  foo(n - 1);
}
```

If you call `foo` with a positive integer, it will simply call itself decreasing
the number until it reaches zero. This is how the call stack behaves if we
execute `foo(10)`:

<iframe width="560" height="315" src="https://www.youtube.com/embed/oorN1hGcgKs" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

As you can see, 10 stack frames get created until `n` reaches zero, at which
point the functions begin to return and all the stacks get deleted.

So if `n` is 10, we have 10 stack frames, if `n` is 100, we have 100 frames and
so on. What happens if `n` is 100,000?

![Ungaught Ranger Error: Maximum call stack size exceeded](/es6-tail-call-optimization/debug6.png)

As said, every stack frame gets created in memory; unfortunately, a program has
a limited amount of memory assigned, so it’s possible that the call stack
becomes too big. In this case, we have an error and the program crashes.

## Tail Call Optimization

Let’s keep our focus on the previous function. As you can clearly see, the last
thing it does before returning is to call itself. This means that, when the
called function returns, `foo` will do nothing, just immediately return to its
caller.

This kind of code allows a `tail call optimization`. With this optimization, if
the last thing a function does is to call another function, instead of creating
a new stack frame the callee will use the caller function’s frame.

In our case, `foo(n-1)` will simply use `foo(n)`’s frame as will `foo(n-2)` etc.
In the end, `foo(0)` will simply return directly to the main program instead of
going through the entire call stack.

This is not only faster but it requires far less memory: instead of creating
100,000 frames we simply have 1 that gets re-used. So our call to `foo(100000)`
will get executed without exceptions.

If you think it’s unlikely you’ll write code like this, think again. Functional
programming is
[rising in popularity](https://medium.com/@jugoncalves/functional-programming-should-be-your-1-priority-for-2015-47dd4641d6b9)
and makes heavy use of tail calls. One of the reasons it hasn’t been used too
much in JavaScript was exactly the lack of tail call optimization.

Also, many languages are now transpiling to JavaScript. Think of Unreal Engine,
which is a C/C++ program, now
[running in Firefox](https://blog.mozilla.org/blog/2014/03/12/mozilla-and-epic-preview-unreal-engine-4-running-in-firefox/).
Those platforms will benefit from this optimization as it’s already a given for
them.

## Current Implementations

This is the part where we usually blame IE for not supporting the new cool
feature, unfortunately this time we have to blame everyone:

[![Usage table for tail-call optimization, no browser implements it](/es6-tail-call-optimization/debug7.png)](<https://kangax.github.io/compat-table/es6/#proper_tail_calls_(tail_call_optimisation)>)

As you can see, only [Babel](https://babeljs.io/) partially supports it. This is
of course about to change in the near future.

If you want to learn more about tail call optimization check the
[ES6 draft](https://people.mozilla.org/~jorendorff/es6-draft.html#sec-tail-position-calls).


ES6 Tail Call Optimization


When I joined [Fundbase](https://www.fundbase.com/) in 2013, I had no clue what
a hedge fund was. As a developer, all I care about is programming languages,
design patterns, and the new cool JS framework that came out two minutes ago.
All this financial jargon has little or no interest to me, right? WRONG!

The first step in solving a problem is to understand it. Otherwise, you’re just
a monkey coder. You can’t add anything to the project besides writing code that
someone else planned.

The only way to escape this is to study.

<div class="highlight">
The cool thing about our job is that we serve other industries and we learn from them.
</div>

I found it quite hard to understand hedge funds since I didn’t have any
financial background. Even
[Hedge Funds for Dummies](http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0470049278.html)
was too complicated for me and many resources out there are trying to help you
invest in hedge funds rather than simply explain how they work. This document is
the guide I needed two years ago and couldn’t find. I hope this can help others,
maybe even future _Fundbasers_.

## What is an Investment Fund?

Before explaining what a hedge fund is, there are some concepts we need to
cover, starting with: “what a fund is”. The
[Cambridge Dictionary](https://dictionary.cambridge.org/) has a good definition
for it:

> **fund** /fʌnd/
>
> noun – an amount of money saved, collected, or provided for a particular
> purpose: a pension/trust fund The hospital has set up a special fund to buy
> new equipment. Contributions are being sought for the disaster fund.

Think about the birthday fund you have in the office: money is collected, saved,
and then spent/provided for the purpose of buying presents for your colleagues.

If you create a fund with the purpose to be invested in and earn a profit, you
have an investment fund. Setting up an investment fund is not as easy as
creating a birthday fund; there are laws that regulate how the fund should work
and often those rules change depending on the country. Generally speaking you
usually have these components:

- Fund Manager: The person who decides how to invest the fund’s assets. When
  people invest in a fund they trust that the fund manager will make the right
  choices to get a return. Therefore, fund managers must have a high level of
  education and professional credentials.
- Fund Administrator: Usually a company to whom the fund manager outsources all
  the administrative tasks such as:
  - Calculating the NAV (Net Asset Value)
  - Preparing reports for shareholders
  - Payment of fund expenses
  - Preparation of fund’s prospectus
- The shareholders: Whomever owns at least one share of a fund’s stock.
- A board of directors or trustees: A group of individuals that are elected as,
  or elected to act as, representatives of the stockholders to establish
  corporate management related policies and to make decisions on major company
  issues. Such issues include the hiring/firing of executives, dividend
  policies, options policies and executive compensation.
- A “marketing” or “distribution” company to promote and sell shares/units of
  the fund.

Of course there’s more than one kind of investment fund. Probably the most
common are mutual funds - let’s quickly see them before we head to hedge funds.

## Mutual Funds

Let’s say that you want to invest some money but your budget is only \$100.
Also, you’re not very experienced in finance. Developing an investing strategy
by yourself might be too hard if not impossible. That’s a typical use case for
mutual funds.

With a mutual fund, you can invest your
$100 and have them managed by a professional team that can set up a diversified portfolio. You’re not going to be the only one who invests in the fund; other people like you will invest $100,
$1000, $10,000 or whatever amount they choose. Then you’ll gain or lose money
proportionally to the gain or loss of the fund.

An important note is the fact that shares are usually issued and can be
purchased or redeemed at any time. Let’s try to clarify this concept. When you
invest in a mutual fund — or any other fund — new shares are created and you own
some of them. The more money you invest the more shares you can get. Every share
is a little part of the fund that you own. To get money you can sell those
shares to someone else or redeem them i.e. return the shares to the fund owner.
The money you get back depends on the fund’s NAV.

## Hedge Funds

Finally!

The idea behind hedge funds is similar to the one for mutual funds: many people
collect their money in order to have investors. The main difference is that
hedge funds are less regulated than normal funds.

<div class="highlight">
Less regulated doesn’t mean illegal. Any fund, not only hedge funds, that acts illegaly gets shut down.
</div>

Thanks to this, hedge funds can adopt unconventional strategies that can lead to
high returns but also to high risks.

To avoid inexperienced people investing in hedge funds without understanding the
risks, the law allows only _qualified investors_ to invest in hedge funds. The
definition of qualified investor depends on each country, but in general it’s an
individual with sufficient investing experience or high net worth and income.
Usually, investors in hedge funds are people with considerable family wealth and
large institutional firms.

Another difference is how the fund manager gets compensated. For other
investments, the managers get a percentage of the AUM (Assets Under Management),
usually around the 0.2%. Hedge funds often follow the “2-and-20” model, meaning
that the manager keeps 2% of the AUM plus 20% of the profits.

This is a very high fee but it’s not all: investors can’t withdraw money at
will. When they invest in the fund, they also agree not to touch their capital
for an agreed upon time period.

With all those limitations, you might expect hedge funds to perform
extraordinarily well. The truth is that, on average, they don’t always
[beat the market](http://www.investopedia.com/ask/answers/03/100903.asp) —
especially if you take into account the manager fee.

On the other hand, if you carefully choose and monitor the existing funds you
can gain astonishing returns. In case you were asking, that’s exactly what
Fundbase is for.


An Introduction to Hedge Funds for Developers