I've just started learning React and got to know about the useState hook. I came across two different ways for setting the state for boolean data. So are these two approaches identical and if not, which one is one should prefer?
const [isChanged, setIsChanged] = useState<boolean>(false)
const onClick = () => {
setIsChanged((prevState) => !prevState) // Approach 1
setIsChanged(!isChanged) // Approach 2
}
Since, as often in code, a simple example paints a thousand words, here's a simple CodeSandbox demo to illustrate the difference, and why, if you want an update based on the value of the state at the point of update, the "updater function" (Approach 1) is best:
https://codesandbox.io/s/stack-overflow-demo-nmjiy?file=/src/App.js
And here's the code in a self-contained snippet:
<div id="root"></div><script src="https://unpkg.com/react@17.0.2/umd/react.development.js"></script><script src="https://unpkg.com/react-dom@17.0.2/umd/react-dom.development.js"></script><script src="https://unpkg.com/@babel/standalone@7.16.7/babel.min.js"></script>
<script type="text/babel" data-type="module" data-presets="env,react">
function App() {
const [count, setCount] = React.useState(0);
// this uses the "good way" but it doesn't really matter here
const incrementPlain = () => setCount((oldCount) => oldCount + 1);
const incrementWithTimeoutBad = () =>
setTimeout(() => setCount(count + 1), 3000);
const incrementWithTimeoutGood = () =>
setTimeout(() => setCount((oldCount) => oldCount + 1), 3000);
return (
<div>
<div>Current count: {count}</div>
<div>
<button onClick={incrementPlain}>
Increment (doesn't matter which way)
</button>
</div>
<div>
<button onClick={incrementWithTimeoutBad}>
Increment with delay (bugged)
</button>
<button onClick={incrementWithTimeoutGood}>
Increment with delay (good)
</button>
</div>
</div>
);
}
ReactDOM.render(<App />, document.getElementById('root'));
</script>Here we have a simple numeric "count" state which is displayed in the markup, together with 3 different buttons that all increment it.
The one on top just does a direct increment - I happen to have used the function form ("approach 1") here because I prefer this style for reasons that will hopefully become clear, but as my comment says, it doesn't actually matter here.
The two below use the two different approaches you outline in the question, and do so after a delay. I've done this with setTimeout here just to be simple - while this isn't particularly realistic, similar effects are commonly seen in real apps where actions call an API endpoint (and even though one hopes that doesn't normally take as long as 3 seconds, the same problems can always be observed with quicker requests - I've just slowed it down to be easier to trigger the bug).
To see the difference, try the following with each of the 2 bottom buttons:
You should see a clear difference in behaviour:
(You can see this more dramatically if you click the bottom button multiple times quickly, then the top one once. And for an even more counterintuitive effect, try pressing the "bugged" bottom button one or more times, then clicking the top button more than once, all within the 3 second time interval.)
Why does this happen? Well, the "buggy" behaviour happens because the function inside the setTimeout is a closure over the outer variable count which is in the scope of the full component function. That means that when it's called with count + 1 as the argument, it will update the count to 1 more than whatever it was at the point the function was defined. Say you do the above sequence from first loading the component where count is 0, then the more detailed sequence of what happens is:
count at that point is equal to 0, its argument, count + 1 is equal to 1.If you know a little bit about JS closures, you might wonder why the count that is accessed in the closure is still 0. Wasn't it previously updated to 1? No, it wasn't, and that's the bit that might be counterintuitive. Notice how count is declared with const? That's right - it never actually changes. The reason the UI updates is because setCount causes React to rerender your component, which means the whole outer function corresponding to the component is called again. This sets up a whole new environment, with a new count variable. React's internals ensure that the useState call now gives back 1 for the current count, which is therefore the value in that new "instance" of the component - but that's irrelevant from the point of view of the function that was put in the event queue to fire after 3 seconds. As far as it's concerned, the count variable - no longer in scope but "remembered" inside that callback as all closed-over variables are - has never changed from 0. The count that's equal to 1 is in a different scope entirely, and forever inaccessible to that first callback.
How does the function argument form - "approach 1" - get round this? Very easily. It doesn't hold any closure at all - the variable inside that function, which I've called oldCount here for the sake of both accuracy and to disambiguate from the outer count - has nothing to do with the count outside. It's the argument to a function that React itself will call internally. When React does call the function, it always supplies the "most up-to-date" state value it has. So you don't have to worry about "stale closures" or anything like that - you're saying "whatever the most recent value was, update the count to be one more than that", and React will take care of the rest.
I've called approach 2 "bugged" here because I think it's reasonable to expect an increment to happen after the timeout, if you've clicked a button that you've set up to do an increment. But this isn't always what you want. If you genuinely wanted the update to be based on the value at the point the button was first clicked, then of course you will prefer Approach 2, and Approach 1 will seem bugged. And in a sense that's more often the case. I highly recommend reading this post by Dan Abramov - one of the core React developers - that explains a crucial difference between class components and functions, that's based on many of the same arguments about closures that came into play here, where normally you do want the event handlers to reference values as they were at the time of render, not when they actually fire after an API request or timeout.
But that post doesn't have anything to do with the "approach 1" form of state-updating functions, which isn't even mentioned in the article. That's because it's irrelevant to the examples given - there'd be no (sensible) way to rewrite those examples to use it. But when you do want to update a state value based on its previous value - as could happen with negating a boolean value, as in the OP example, or incrementing a counter as in mine, I would argue that it's more natural that you always want that "previous value" to be up to date. There are 2 buttons which both should increment a value, albeit in different ways - I think it's reasonable to call it bugged if clicking both of them, depending on the timing, may only increment once in total.
But that's of course up to each individual component or application to decide. What I hope I've done here is explain what the difference is, and give you a basis to choose which might be best. But I do believe that 90+% of the time, if you have the option of using the function argument ("approach 1"), it will be better, unless you know it isn't.
the first approach
setIsChanged((prevState) => !prevState)
to make sure that you always have the last state before changing it.
The simple answer is this:
setIsChanged((prevState) => !prevState)
In this case the setter setIsChanged provided by the useState hook is passing it's own internal reference value, so it's always update, despite the whole async issue with useState.
In short, you're using the internal state value with prevState.
setIsChanged(!isChanged)
In this case, you're using the value provided by the useState hook to your COMPONENT, but not an internal ref. In this case you're working with data locally in your component that could be stale due to how components work asynchronously.
For most cases, the second approach works just fine and is by far the most common. You'll only use the second one if you're updating the state in several places at once or feel it could get out of sync.
You can read more about that here
State updates are asynchronous which means they are not updated immediately. They are scheduled. If your state depends on previous state then use 1st approach.
if your updatedState does not depend on previous state used 2nd approach. Example:
useState is async so sometimes this way does not work
setEditing(!prevState)
first the all we need the previous value, i think this way is best
setEditing((prevState) => !prevState)
you can try custom hooks
useToggle.js
import { useReducer } from 'react';
function toggler(currentValue, newValue) {
return typeof newValue === 'boolean' ? newValue : !currentValue;
}
function useToggle(initialValue = false) {
return useReducer(toggler, initialValue);
}
export default useToggle;
use like
import useToggle from './useToggle';
const App = () => {
const [isShown, toggle] = useToggle();
return <button>{isShown ? 'show' : 'hide'}</button>;
};
export default App;
