If you’ve been working with React for a while, you’ve probably used useState.
Here’s a quick example of the API:
function Counter() {
const [count, setCount] = React.useState(0)
const increment = () => setCount(count + 1)
return <button onClick={increment}>{count}</button>
}
So, you call useState with the initial state value, and it returns an array
with the value of that state and a mechanism for updating it (which is called
the “state dispatch function”). When you call the state dispatch function, you
pass the new value for the state and that triggers a re-render of the component
which leads to useState getting called again to retrieve the new state value and
the dispatch function again.
This is one of the first things you learn about state when you’re getting into
React (at least, it is if you
learn from my free course). But there’s a
lesser known feature of both the useState call and the dispatch function
that can be useful at times:
function Counter() {
const [count, setCount] = React.useState(() => 0)
const increment = () => setCount(previousCount => previousCount + 1)
return <button onClick={increment}>{count}</button>
}
The difference is that useState in this example is called with a function
that returns the initial state (rather than simply passing the initial state)
and setCount (dispatch) is called with a function that accepts the previous
state value and returns the new one. This functions exactly the same as the
previous example, but there are subtle differences that we’ll get into in this
post. I teach about this in
my free React course as well, but I get asked
about it enough that I thought I’d write about it as well.
If you were to add a console.log to the function body of the Counter function,
you would find that the function is run every time you click the button. This
makes sense because your Counter function is run during every render phase and
clicking the button triggers the state update which triggers the re-render. One
thing you need to keep in mind is that if the function body runs, that means all
the code inside it runs as well. Which means any variables you create or
arguments you pass are created and evaluated every render. This is normally not
a big deal because JavaScript engines are very fast and can optimize for this
kind of thing. So something like this would be no problem:
const initialState = 0
const [count, setCount] = React.useState(initialState)
However, what if the initial value for your state is computationally expensive?
const initialState = calculateSomethingExpensive(props)
const [count, setCount] = React.useState(initialState)
Or, more practically, what if you need to read into localStorage which is an
IO operation?
const initialState = Number(window.localStorage.getItem('count'))
const [count, setCount] = React.useState(initialState)
Remember that the only time React needs the initial state is initially 😉
Meaning, it only really needs the initial state on the first render. But because
our function body runs every time there’s a re-render of our component, we end
up running that code on every render, even if its value is not used or needed.
This is what the lazy initialization is all about. It allows you to put that
code in a function:
const getInitialState = () => Number(window.localStorage.getItem('count'))
const [count, setCount] = React.useState(getInitialState)
Creating a function is fast. Even if what the function does is computationally
expensive. So you only pay the performance penalty when you call the function.
So if you pass a function to useState, React will only call the function when
it needs the initial value (which is when the component is initially rendered).
This is called “lazy initialization.” It’s a performance optimization. You
shouldn’t have to use it a whole lot, but it can be useful in some situations,
so it’s good to know that it’s a feature that exists and you can use it when
needed. I would say I use this only 2% of the time. It’s not really a feature I
use often.
This one’s a little bit more complicated. The easiest way to explain what it’s
for is by showing an example. Let’s say that before we can update our count
state, we need to do something async:
function DelayedCounter() {
const [count, setCount] = React.useState(0)
const increment = async () => {
await doSomethingAsync()
setCount(count + 1)
}
return <button onClick={increment}>{count}</button>
}
Let’s say that async thing takes 500ms. That’s rendered here, click this button
three times really fast:
If you clicked it fast enough, you’ll notice that the count was only incremented
to 1. But that’s weird, because if you added a console.log to the increment
function, you’ll find that it’s called three times (once for every click), so
why is the count state not updated three times?
Well, this is where things get tricky. The fact is that the state is updated
three times (once for every click), but if you added a console.log(count)
right above the setCount call, you’d notice that count is 0 every time! So
we’re calling setCount(0 + 1) for every click, even though we actually want to
increment the count.
So why is the count 0 every time? It’s because the increment function that
we’ve given to React through the onClick prop on that button “closes over”
the value of count at the time it’s created. You can
learn more about closures from mdn.io/closure, but in
short, when a function is created, it has access to the variables defined
outside of it and even if what those variables are assigned to changes.
The problem is that we’re actually calling the exact same increment function
which has closed over the value of 0 for the count before it has a chance to
update based on the previous click and it stays that way until React re-renders.
So you might think we could solve this problem if we could just trigger a
re-render before the async operation, but that won’t do it for us either. The
problem with that approach is that while increment has access to count for
this render, it won’t have access to the count variable for the next render.
In fact, on the next render, we’ll have a completely different increment
function which has access to a completely different count variable. So we’ll
effectively have two copies of all our variables each render. (Garbage
collection typically cleans up the copies and we only need to worry about the
here-and-now.) But because the count hasn’t been updated yet, when the new
copy of increment is created, the value of count is still 0 and that’s why
it’s 0 when we click the button the second time as well as the first.
You’ll notice that if you wait for the count value to update before you click
the button again, everything works fine, this is because we’ve waited long
enough for the re-render to occur and a new increment function has been
created with the latest value for count.
But obviously, this is a little confusing and it’s also a little problematic. So
what’s the solution? Function updates! What we really need is some way to
determine the previous value of count when we’re making our update so we can
determine it based on the previous value of count.
Any time I need to compute new state based on previous state, I use a function
update.
So here’s the solution:
function DelayedCounter() {
const [count, setCount] = React.useState(0)
const increment = async () => {
await doSomethingAsync()
setCount(previousCount => previousCount + 1)
}
return <button onClick={increment}>{count}</button>
}
Try that here:
You can click that as frequently as you like and it’ll manage updating the count
for every click. This works because we no longer worry about accessing a value
that may be “stale” but instead we get access to the latest value of the
variable we need. So even though the increment function we’re running in has
an older version of count, our function updater receives the most up-to-date
version of the state.
I should add that you won’t have this same problem if you’re using useReducer
because that will always receive the most recent version of the state (as the
first argument to your reducer), so you don’t need to worry about stale state
values. Though an exception to this would be if your state update is determined
by props or some external state, in which case you might need a useRef to help
ensure you’ve got the most current version of that prop or external state. But
that’s a subject for another blog post…
I hope that helps explain the what/why/how of useState lazy initializers and
dispatch function updates. Lazy initializers are useful to improve performance
issues in some scenarios, the dispatch function updates help you avoid issues
with stale values.
If you enjoyed this post, you might also like
How to implement useState with useReducer
and Should I useState or useReducer.
Good luck!
Source link
