-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Re-sort rerender queue if modified while we are processing rerenders #3871
Merged
Commits on Feb 3, 2023
-
Add test for context propagation compat bug
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.
Configuration menu - View commit details
-
Copy full SHA for ef025df - Browse repository at this point
Copy the full SHA ef025dfView commit details -
Configuration menu - View commit details
-
Copy full SHA for 8e93eb7 - Browse repository at this point
Copy the full SHA 8e93eb7View commit details -
Remove unnecessary top loop since the inner loop will always run unti…
…l the rerenderQueue is empty and length == 0
Configuration menu - View commit details
-
Copy full SHA for fc935fb - Browse repository at this point
Copy the full SHA fc935fbView commit details -
Configuration menu - View commit details
-
Copy full SHA for 4e55f55 - Browse repository at this point
Copy the full SHA 4e55f55View commit details
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.