Skip to content

Commit d396238

Browse files
committed
await in event handler cause immediate rerender
Signed-off-by: jzz <[email protected]>
1 parent eda939c commit d396238

File tree

2 files changed

+10
-9
lines changed

2 files changed

+10
-9
lines changed

src/content/learn/queueing-a-series-of-state-updates.md

Lines changed: 9 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -63,20 +63,21 @@ But there is one other factor at play here. **React waits until *all* code in th
6363

6464
> **Note:** When using `await` inside an event handler:
6565
>
66-
> - React processes all state updates made before the `await` immediately,
67-
> which triggers a rerender before the handler completes.
66+
> - React processes all state updates made before the `await` immediately,which triggers a rerender
67+
> before the handler completes.
6868
>
69-
> - This behavior differs from synchronous event handlers, where React
70-
> waits until the entire handler finishes.
69+
> - This behavior differs from synchronous event handlers, where React waits until the entire handler
70+
> finishes.
7171
>
72-
> - Any state updates after the `await` will be treated as a separate batch,
73-
> potentially causing multiple renders.
72+
> - Any state updates after the `await` will be treated as a separate batch,potentially causing multiple
73+
> renders.
7474
>
75-
> To avoid this behavior, keep all state updates within a single synchronous
76-
> batch, or avoid using `await` inside event handlers when possible.
75+
> To avoid this behavior, keep all state updates within a single synchronous batch, or avoid using `await`
76+
> inside event handlers when possible.
7777
7878
---
7979

80+
8081
<Illustration src="/images/docs/illustrations/i_react-batching.png" alt="An elegant cursor at a restaurant places and order multiple times with React, playing the part of the waiter. After she calls setState() multiple times, the waiter writes down the last one she requested as her final order." />
8182

8283
This lets you update multiple state variables--even from multiple components--without triggering too many [re-renders.](/learn/render-and-commit#re-renders-when-state-updates) But this also means that the UI won't be updated until _after_ your event handler, and any code in it, completes. This behavior, also known as **batching,** makes your React app run much faster. It also avoids dealing with confusing "half-finished" renders where only some of the variables have been updated.

src/content/reference/react/useMemo.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1105,7 +1105,7 @@ function ChatRoom({ roomId }) {
11051105
const connection = createConnection(options);
11061106
connection.connect();
11071107
return () => connection.disconnect();
1108-
}, [options]); // ✅ Only changes when create option changes
1108+
}, [options]); // ✅ Only changes when createOption changes
11091109
// ...
11101110
```
11111111

0 commit comments

Comments
 (0)