Re-sort rerender queue if modified while we are processing rerenders #3871
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
📊 Tachometer Benchmark ResultsSummaryduration
usedJSHeapSize
Results02_replace1k
duration
usedJSHeapSize
run-warmup-0
run-warmup-1
run-warmup-2
run-warmup-3
run-warmup-4
run-final
03_update10th1k_x16
duration
usedJSHeapSize
07_create10k
duration
usedJSHeapSize
filter_list
duration
usedJSHeapSize
hydrate1k
duration
usedJSHeapSize
many_updates
duration
usedJSHeapSize
text_update
duration
usedJSHeapSize
todo
duration
usedJSHeapSize
|
|
Size Change: +176 B (0%) Total Size: 53.3 kB
ℹ️ View Unchanged
|
JoviDeCroock
approved these changes
Jan 27, 2023
Found a difference between how React and Preact propagate context. It shows up when using react-router and a component triggers a location update (e.g. `history.push`) and at the same time triggers a local state update.
## The setup
First, how React Router works. The `Router` component watches the pages current location and provides it on a context. Let's call this context `RouterContext`. The `Route` component consumes this `RouterContext`, but also modifies it and re-provides the new value on a new instance of `RouterContext.Provider`.
So if we have a `Page` component that lives under a `Router` and `Route` components, the virtual DOM tree looks something the following. Let's say the initial value of the provided location in `RouterContext` is `/page/1`
```jsx
<App>
<Router>
<RouterContext.Provider> {/* location: /page/1 */}
<Route>
<RouterContext.Consumer>
<RouterContext.Provider> {/* location: /page/1 */}
<Page>
<button>
```
Let's say the `button` under `Page` has a click handler that triggers a location update on `Router` as well as updates some local state:
```jsx
function Page() {
const history = useHistory(); // Magical hook that triggers a state update in the Router with a new location entry
const [value, setValue] = useState(1);
// let's pretend to read the current location and value for some purpose
const { location } = useContext(RouterContext);
console.log({ location, value });
return (
<button
onClick={() => {
history.push('/page/2'); // Triggers an state update in the Router component
setValue(2); // Triggers a state update in Page
}}
>
Update
</button>
);
}
```
Some things to note about this virtual tree:
1. The `RouteContext.Consumer` under `Route` is subscribed to its parent `RouteContext.Provider` (the one owned by `Router`)
2. The `Page` component is subscribed to it's nearest parent `RouteContext.Provider`, which in this case is the one owned by `Route`, not `Router`.
On initial render, `Page` would log `{ location: /page/1, value: 1 }`.
## The bug
So what happens in Preact when we click this button? Two state updates are triggered: one on `Router` and one `Page`. So our rerender queue looks like [`Router`, `Page`]. Upon rerendering Router, we update the location value we pass to the first `RouterContext.Provider` to `/page/2` and trigger updates to all of the `RouterContext` consumers. Let's re-examine our render queue and virtual DOM tree:
```jsx
// renderQueue: [Page, RouterContext.Consumer]
<App>
<Router>
<RouterContext.Provider> {/* location: /page/2 */}
<Route>
<RouterContext.Consumer>
<RouterContext.Provider> {/* location: /page/1 */}
<Page>
<button>
```
A couple things to note. Our rerendering stops after the first `RouterContext.Provider` runs. Context providers just return `props.children` so our `vnodeID` optimization will kick in, see the children of the `Provider` didn't get no VNodes and stop rerendering there. Because of this, the `RouterContext.Consumer` under `Route` has NOT rerendered yet, so the `RouterContext.Provider` that it owns has not received the updated context. And since the `Page` component is subscribed to the `RouterContext.Provider` that `Route` owns, it still would see the old context.
So, since rerendering stopped after the first `RouterContext.Provider`, the next component that rerenders is `Page` (remember, it triggered it's own local state update). At this point `Page` will log `{ location: /page/1, value: 2 }`. This log represents the developer-observable bug.
The `onClick` handler of the button contains both the `history.push()` and `setValue()` calls and so the developer expects that the next time `Page` renders will be both a new location and a new state value. And logic that assumes this will fail.
## Completing the flow
If we continue with Preact's rendering (for completeness), once the `RouterContext.Consumer` rerenders, it'll rerender the second `RouterContext.Provider` which trigger rerenders to its subscribers, namely `Page`. A this point `Page` will rerender again but with the both the updated location context and the new state and so will log `{ location: /page/2, value: 2 }`.
## React's behavior
In this case, React handles the state propagation and local state update in one pass down the render tree. Presumably, changes to context synchronously mark consumers as needing updates (I haven't personally validated this yet). So as React walks down the tree, it rerenders the `Router`, the first `RouterContext.Provider`, sees the `RouterContext.Consumer` as needing a rerender, which causes a render of the second `RouterContext.Provider`, and ultimately rerenders the `Page` component with both it's local state update and the location update from its parent `RouterContext.Provider`. In this case, `Page` only rerenders once with both updates.
…l the rerenderQueue is empty and length == 0
andrewiggins
force-pushed
the
context-fix
branch
from
e61c9a1
to
4e55f55
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
By re-sorting the rerender queue while flushing it, we ensure we always rerender from the top-down of the vdom tree. This behavior is especially important for flushing context updates which trigger updates of nodes further down the tree. We should always process these top-down so the context updates propagate before other rerenders which may depend on the context update rerender. See the commit message in 672782a for a more detailed description of the bug and the test that this PR adds.