Putting props to useState
Tags: javascript, react, typescript, usestate
Published: 2020-12-30 10:49:24

### Note:

The examples are interactive on my blog, so you might have a better experience reading it there:

[Putting props to useState](https://tkdodo.eu/blog/putting-props-to-use-state)

---

In the [first part](https://tkdodo.eu/blog/dont-over-use-state) of the useState pitfalls series, I talked about avoiding state all together for derived state.

This part is about a common scenario, where we want to initialize our state with values we get as props. This is something we probably do a lot, and it's not per-se wrong, but it has some potential issues that we need to be aware of.

# The example

I will use a classic list / detail use-case as example. We have a list of persons, and selecting one of them will result in a detail form being filled. We want to show the persons' email address in the detail form, and also have an apply button that will update that data.

```js
const persons = [
    {
        id: 1,
        name: 'Dominik',
        email: 'dominik@dorfmeister.cc',
    },
    {
        id: 2,
        name: 'John',
        email: 'john@doe.com',
    },
]

function App() {
    const [selected, setSelected] = React.useState(persons[0])

    return (
        <div>
            {persons.map((person) => (
                <button type="button" key={person.id} onClick={() => setSelected(person)}>
                    {person.id === selected.id ? person.name.toUpperCase() : person.name}
                </button>
            ))}
            <DetailView initialEmail={selected.email} />
        </div>
    )
}

function DetailView({ initialEmail }) {
    const [email, setEmail] = React.useState(initialEmail)

    return (
        <div>
            <input
                type="text"
                value={email}
                onChange={(event) => setEmail(event.target.value)}
            />
            <button type="button" onClick={() => alert(email)}>
                Apply
            </button>
        </div>
    )
}
```

# useState initial value

You might notice right away that the example is _not_ working. You can edit the email address and click _Apply_, but if you click on _John_, the input field will not update.

As much as React wants us to [think in hooks](https://wattenberger.com/blog/react-hooks) rather than in lifecycles, when it comes to state, there is a big difference between the first render (also known as _mount_) and further renders (better known as _re-renders_).

The initial value of a useState hook is always _discarded_ on re-renders - it only has an effect when the component _mounts_.

When you click on _John_, the DetailView component will be re-rendered (because it already exists on the screen), which means that John's email will not be put into our state. Bummer, because we still need the local state to edit the email address (to keep the draft changes). We don't want to update the person Array directly, because we might never click Apply.

I know three ways to handle this and similar use-cases:

# 1. Conditionally render the DetailView

We do this a lot when we are using Modals or other components that appear on screen.

Showing the DetailView in a Modal will magically make our code above work, because Modals are usually rendered conditionally. When we click on _John_, we mount a Modal, thus the useState initial value will be respected. When the user closes the Modal, it will be _unmounted_, and the next time a person is selected it will be _mounted_ again.

Here is how that might look:

```js
const persons = [
    {
        id: 1,
        name: 'Dominik',
        email: 'dominik@dorfmeister.cc',
    },
    {
        id: 2,
        name: 'John',
        email: 'john@doe.com',
    },
]

function App() {
    const [selected, setSelected] = React.useState()

    const close = () => setSelected(undefined)

    return (
        <div>
            {persons.map((person) => (
                <button type="button" key={person.id} onClick={() => setSelected(person)}>
                    {person.name}
                </button>
            ))}
            {selected && (
                <div
                    style={{
                        position: 'fixed',
                        top: '0',
                        left: '0',
                        paddingTop: '100px',
                        width: '100%',
                        height: '100%',
                        backgroundColor: 'rgba(0,0,0,0.4)',
                    }}
                >
                    <div
                        style={{
                            display: 'flex',
                            justifyContent: 'center',
                            width: '80%',
                            height: '50vh',
                            margin: 'auto',
                            backgroundColor: 'white',
                        }}
                    >
                        <DetailView initialEmail={selected.email} close={close} />
                        <span style={{ cursor: 'pointer' }} onClick={close}>
                            &times;
                        </span>
                    </div>
                </div>
            )}
        </div>
    )
}

function DetailView({ initialEmail, close }) {
    const [email, setEmail] = React.useState(initialEmail)

    return (
        <div>
            <input
                type="text"
                value={email}
                onChange={(event) => setEmail(event.target.value)}
            />
            <button
                type="button"
                onClick={() => {
                    alert(email)
                    close()
                }}
            >
                Apply
            </button>
        </div>
    )
}
```

Excuse my css, I suck at this part of web development 😅

But the example works now. That is because the Modal conditionally renders our DetailView, which will make it mount again.

I'm sure many of you have done that a lot, and it's a valid solution. But be aware that this only works because you are rendering the DetailView in the Modal. If you want the DetailView to be renderable everywhere, we would need a different solution.

# 2. Lifting state up

You've probably heard this phrase before, the official React docs also have [a section on that topic](https://reactjs.org/docs/lifting-state-up.html).

For this example, it basically just means to take the draft state and move it further up the tree, thus making our DetailView a fully controlled component. Since the DetailView then doesn't need any local state at all, we won't have the problem of putting props into state.

```js
const persons = [
    {
        id: 1,
        name: 'Dominik',
        email: 'dominik@dorfmeister.cc',
    },
    {
        id: 2,
        name: 'John',
        email: 'john@doe.com',
    },
]

function App() {
    const [selected, setSelected] = React.useState(persons[0])
    const [email, setEmail] = React.useState(selected.email)

    return (
        <div>
            {persons.map((person) => (
                <button
                    type="button"
                    key={person.id}
                    onClick={() => {
                        setSelected(person)
                        setEmail(person.email)
                    }}
                >
                    {person.id === selected.id ? person.name.toUpperCase() : person.name}
                </button>
            ))}
            <DetailView email={email} setEmail={setEmail} />
        </div>
    )
}

function DetailView({ email, setEmail }) {
    return (
        <div>
            <input
                type="text"
                value={email}
                onChange={(event) => setEmail(event.target.value)}
            />
            <button type="button" onClick={() => alert(email)}>
                Apply
            </button>
        </div>
    )
}
```

Now, the App has full control over all the state, and the DetailView is just a so-called "dumb component". This approach is feasible for many use-cases, but it's not without drawbacks.

Typing in the input field will now re-render the whole App with every keystroke. While this is not a problem for this small example, it might be a problem for bigger Apps. People often resort to global state managers because they promise to re-render efficiently.

Once could also argue that the scope of the draft email state is now too big. Why does the App even care about that, it probably only cares about the new email once the user hits Apply.

The third approach is kind of the middle ground between the two: Keep the same ux and the scope of the draft state small, but still re-mount your form when you need to.

# 3. Fully uncontrolled with a key

```js
const persons = [
    {
        id: 1,
        name: 'Dominik',
        email: 'dominik@dorfmeister.cc',
    },
    {
        id: 2,
        name: 'John',
        email: 'john@doe.com',
    },
]

function App() {
    const [selected, setSelected] = React.useState(persons[0])

    return (
        <div>
            {persons.map((person) => (
                <button type="button" key={person.id} onClick={() => setSelected(person)}>
                    {person.id === selected.id ? person.name.toUpperCase() : person.name}
                </button>
            ))}
            <DetailView key={selected.id} initialEmail={selected.email} />
        </div>
    )
}

function DetailView({ initialEmail }) {
    const [email, setEmail] = React.useState(initialEmail)

    return (
        <div>
            <input
                type="text"
                value={email}
                onChange={(event) => setEmail(event.target.value)}
            />
            <button type="button" onClick={() => alert(email)}>
                Apply
            </button>
        </div>
    )
}
```

This is exactly the same code as in the first example, with just one small change:

```diff
- <DetailView initialEmail={selected.email} />
+ <DetailView key={selected.id} initialEmail={selected.email} />
```

## React keys

The `key` attribute on a React component is a special thing. Keys are mostly used for lists to signalize stability to React,
so that the reconciler knows which elements can be re-used, and thus re-rendered.

However, you can also just put a key attribute on any component to tell React: "Please mount this whenever the key changes. As long as the key is the same, please re-render".

This can be seen a little bit like the dependency array in effects. If it changes, compared to the previous render, React will re-run the "mounting" of the component.

If you want to know more, please read this [explanation about reconciliation](https://reactjs.org/docs/reconciliation.html).

# The non-solution

You might be tempted to solve the problem with an effect that "syncs" props to state:

```js
function DetailView({ initialEmail }) {
    const [email, setEmail] = React.useState(initialEmail)

    React.useEffect(() => {
        setEmail(initialEmail)
    }, [initialEmail])

    return (...)
}

```

I would consider effects like these generally an anti-pattern. If effects are used for syncing, they should be used to sync React state with something _outside_ of React, e.g. with localstorage.

But here, we are syncing something that already lives inside React with React state. Further, the condition on which we sync does not really reflect what we want to achieve: We want to reset the state whenever another person is selected, _not_ necessarily when the email changes.

The first solution does this via conditional rendering, the second one by setting the state explicitly when the button that selects a person is clicked, and the third one by providing a stable key (the selected persons' id).

Emails might be a suboptimal example, because they are generally also unique, but what if two persons have the same data (e.g. a firstName)? The effect won't re-run, even though we click on a different person, and thus the draft state is not reset.

Similarly, what if the data changes in the parent component (e.g. because of a re-fetch by [react-query](https://react-query.tanstack.com/docs/guides/window-focus-refetching)), but our user has already changed the value in the input field? Would we really want to override the user input in these cases?

So, effects like these open you up to a bunch of hard-to-track errors in corner cases that you'd better avoid.

# Takeaways

Personally, I don't have a preferred solution. I have used all three approaches occasionally.

The detail view owning the draft state has some advantages, but unmounting comes with a bit of a cost, and you don't always have a stable key or a clear indication when a component should be reset.

Lifting state up also has advantages, as fully controlled components are usually easier to reason about, but it might not always be easily doable in large applications.

Whatever you decide, please, don't use the syncing state "solution". To me, this approach is similar to the old _componentWillReceiveProps_ lifecycle, which was also used to sync props with state. I don't recall that ending well. [Here](https://reactjs.org/blog/2018/06/07/you-probably-dont-need-derived-state.html) is a very good article from 2018 by [Brian Vaughn](https://twitter.com/brian_d_vaughn) on that anti-pattern, which also heavily inspired this article.

---

Which solution do you prefer? Leave a comment below ⬇️