React Native State Delay: setState Not Updating Value Immediately in Function

State not reflecting its new value immediately after calling a setter isn't a bug — React state updates are intentionally asynchronous and batched, meaning the variable you're reading right after calling the setter still reflects the value from before that update, until the component actually re-renders with the new state.

The Problem

Code that sets state and then immediately reads the same state variable sees the old, pre-update value, not the newly set one:

const [count, setCount] = useState(0);

function handlePress() {
  setCount(count + 1);
  console.log(count); // still logs the OLD value, not count + 1
}

The state does eventually update correctly (visible in the next render), which makes the immediate, same-function read of the stale value confusing at first.

Why It Happens

Calling a state setter function (from useState) doesn't immediately mutate the variable in place — it schedules a state update and triggers a re-render, and the new value only becomes available once that re-render actually happens and the function component runs again from the top with the updated state. Within the same function call where you invoked the setter, the original count variable remains a closure over the value it had when that specific render/function execution began — it doesn't retroactively update mid-execution. This is intentional, deliberate React behavior, allowing React to batch multiple state updates together efficiently rather than re-rendering synchronously after every single individual state change.

The Fix

If you need to use the updated value immediately after setting it, compute the new value in a local variable first, and use that local variable for any immediate logic, rather than relying on the state variable to have already updated:

function handlePress() {
  const newCount = count + 1;
  setCount(newCount);
  console.log(newCount); // correctly logs the new value
  doSomethingWith(newCount);
}

If you need to react to a state change after it's actually been applied (rather than computing the new value manually alongside the setter call), use useEffect with the relevant state as a dependency, which runs after the component has re-rendered with the updated value:

useEffect(() => {
  console.log('count updated to:', count);
  // logic that should run whenever count actually changes, after the update applies
}, [count]);

For state updates that depend on the previous state value, especially in scenarios with potential rapid, multiple updates (like several increments happening close together), use the functional updater form of the setter rather than referencing the outer closure's count variable directly, since this form always receives the genuinely latest state value, avoiding subtle bugs from stale closures in more complex scenarios:

setCount(prevCount => prevCount + 1);

This functional form is particularly important when multiple state updates might be batched together or called in quick succession — using setCount(count + 1) twice in a row within the same function, for example, both calls reference the same stale count value from that render, potentially resulting in only a single net increment instead of two, while the functional form setCount(prev => prev + 1) called twice correctly compounds, since each call receives the genuinely latest pending value.

Still Not Working?

If you're specifically trying to read updated state from within an event handler triggered by native gesture or animation callbacks, and the timing still seems inconsistent even after applying the patterns above, check whether the specific event system you're working with (React Native's gesture handling, in particular) has its own separate timing/threading considerations distinct from standard React state batching — some native-driven callbacks run outside React's normal render cycle timing in ways that can introduce additional, related-but-distinct timing subtleties beyond the standard React state batching behavior covered here, requiring library-specific patterns (like using a ref alongside state for values genuinely needed synchronously within a native callback) rather than relying purely on React state timing alone.