Making sense of closure in JavaScript with React Hooks

Kris Grint — Thu, 23 May 2019 20:19:25 +0000

A closure is the combination of a function and the lexical environment within which that function was declared. MDN

What do we really mean when we talk about closure in JavaScript? Closure occurs when an inner function has access to variables scoped to the outer function, even after the outer function has returned:

const outerFunction = () => {
    const firstName = 'John';
    const secondName = 'Doe';

    const innerFunction = () => {
        console.log(`${firstName} ${secondName}`);
    };

    return innerFunction;
};

In the example above, outerFunction is comprised of two variables and a second function. When the function is run, it will return innerFunction:

const closureExample = outerFunction();
closureExample();

By assigning the returned inner function to a variable called closureExample and then executing it, we will see the values of firstName and lastName logged out to the console. This is because innerFunction has closure over outerFunction: it has access to its properties even after the function where they were scoped to has been executed.

The new Hooks API in React is a great example of closure in action. One of these hooks, useEffect(), is used to execute code after your component has finished rendering. It's similar to React's componentDidMount lifecycle method:

import React, { useEffect } from 'react';

const Header = props => {
    const { pageTitle, headerTitle } = props;

    useEffect(() => {
        document.title = headerTitle;
        return () => {
            document.title = pageTitle;
        }
    });

    return (
        <h1>{headerTitle}</h1>
    );
}

In the example above, our Header component receives two props called headerTitle and pageTitle and returns the former surrounded by h1 tags. After rendering the heading, the useEffect() hook calls a function which will also set the title of the document to headerTitle. The function passed to useEffect() itself returns a function which, when called, will change the title of the document to pageTitle.

Because the useEffect() hook will run the function passed to it after the component has returned, but the function sets the title of the document to a property scoped to that component, we can say that it has closure over the component's properties. A second instance of closure occurs when React calls the function which was itself returned from this function, which will occur after the component is unmounted from the DOM in a way similar to the componentWillUnmount lifecycle method. This final function sets the document title to the value of pageTitle, also scoped to the component which has long since returned. This pattern is a good way of 'cleaning up' after your component, as you can do things like reset values to their defaults or cancel outbound fetch requests.

For the longest time, closure in JavaScript has been more of a question to catch out developers in job interviews than a feature of the language with practical value. With React's Hooks API, it's becoming a lot easier to see examples of this concept in the wild.

Safely copying nested objects in JavaScript

Kris Grint — Thu, 16 May 2019 22:03:31 +0000

A fundamental concept when managing state in JavaScript is that you should never mutate the data directly. In large applications, respecting this rule can become difficult when state is stored in nested objects. This is particularly relevant if you are using libraries such as Redux, as the docs suggest:

The key to updating nested data is that every level of nesting must be copied and updated appropriately. This is often a difficult concept for those learning Redux, and there are some specific problems that frequently occur when trying to update nested objects. These lead to accidental direct mutation, and should be avoided.

In order to avoid mutating state directly, we need to make a copy of the object, modify it as appropriate, and then use it in place of the original. This is the principle behind React's setState method, which accepts an object which it will swap for the existing one in your component's state.

Reference vs. value types in JavaScript

JavaScript objects are data types which are passed by reference to the location in memory, as opposed to strings or integers which are passed by their actual value. This means that copying objects can be tricky, because assignment might not work as you expect.

Take this example of a user object:

const state = {
    name: 'John',
    address: {
        city: 'London',
        country: {
            countryName: 'United Kingdom',
            countryCode: 'UK',
        },
    },
};

We cannot make a copy of this object by assigning it to a new variable:

const copyState = state;
copyState.name = 'Jane';
console.log(copyState === state); // true
console.log(state.name); // 'Jane'

The copyState variable is pointing to the same reference as the original state object, which is why the strict equals check returns true. When we modify the name property of the copyState object, we are mutating the same object which the state variable is pointing to. Often this is not what is intended.

Spread operator

The spread operator or syntax (...) can be used to make a shallow copy of an object.

const shallowCopyState = { ...state };
shallowCopyState.name = 'Jane';
console.log(shallowCopyState === state); // false
console.log(state.name); // 'John'

Now, our two variables are pointing to different object references. Modifying the value of the name property on the shallowCopyState object has no effect on the original state object and the strict equals check returns false.

Shallow in this context means that for any given object that is spread, the uppermost level of the new variable is an object containing the same properties and values of the original object, but at a new reference in memory. Any lower level or nested objects, however, will remain pointing to their original references:

const shallowCopyState = { ...state };
console.log(shallowCopyState === state); // false
shallowCopyState.address.city = 'Paris';
console.log(shallowCopyState.address === state.address); // true
console.log(state.address.city); // 'Paris'

To copy a deep object like our user object safely, we also need to use the spread operator at the nested level of the object:

const deeperCopyState = {
    ...state,
    address: {
        ...state.address,
    },
};
deeperCopyState.address.country.countryCode = 'FR';
console.log(deeperCopyState.address === state.address); // false
console.log(deeperCopyState.address.country === state.address.country); // true
console.log(state.address.country.countryCode); // 'FR'

As you can see in the above example, the nested object for address is different across the two variables, but its nested object for country is still pointing to the same reference as in our original state variable. We could fix this by going down further, but at this point it may be easier to reach for a library to help us, such as Immer.

Immer

The Immer library consists of a produce function which takes an existing object and returns a new one. Because you can also dictate which properties on the new object will be updated, it's an excellent way of safely creating state objects:

const state = {
    name: 'John',
    address: {
        city: 'London',
        country: {
            countryName: 'United Kingdom',
            countryCode: 'UK',
        },
    },
};

const immerState = immer.produce(state, draftState => {
    draftState.name = 'Jane';
    draftState.address.city = 'Paris';
    draftState.address.country.countryName = 'France';
    draftState.address.country.countryCode = 'FR';
});

The immerState variable is completely decoupled to the original state object, and shares no references to it:

console.log(immerState === state); // false
console.log(immerState.address === state.address); // false
console.log(immerState.address.country === state.address.country); // false
console.log(state.address.country.countryCode); // 'UK'
console.log(immerState.address.country.countryCode); // 'FR'

Finally

It's worth referring back to the Redux docs about nested objects:

Obviously, each layer of nesting makes this harder to read, and gives more chances to make mistakes. This is one of several reasons why you are encouraged to keep your state flattened.

If you find yourself handling objects that are many levels deep, and which require extensive use of the spread operator or a library like Immer, it is worth considering if there's a way to simplify the composition of such objects. If, however, you find yourself in a codebase where these structures are common, hopefully this article will help you keep your state immutable.