-
Notifications
You must be signed in to change notification settings - Fork 46.9k
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
forwardRef() components should not re-render on deep setState() #12690
Conversation
if (hasLegacyContextChanged()) { | ||
// Normally we can bail out on props equality but if context has changed | ||
// we don't do the bailout and we have to reuse existing props instead. | ||
} else if (workInProgress.memoizedProps === nextProps) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should also compare workInProgress.ref
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With what?
(Sorry if I'm being dense)
Also, is it possible for a deep update to influence the value of a ref above it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, is it possible for a deep update to influence the value of a ref above it?
I'm not sure, but it seems conceivable that a ref
could be the only changed "prop" (if it's an inline arrow function for a non-PureComponent
) and we might bail out when we shouldn't here?
Although in that case it probably wouldn't matter anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm... maybe Foo
gets new properties that causes it to recreate the ref, but only a filtered set of those props are passed through to the ForwardRef
component, so from it's POV nothing has changed?
Maybe this is too contrived.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe Foo gets new properties that causes it to recreate the ref, but only a filtered set of those props are passed through to the ForwardRef component, so from it's POV nothing has changed?
OK, that sounds potentially plausible. If you find any free time to hack on this I'd appreciate a test.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think maybe this is too contrived to be a real concern.
Ref callbacks would be re-invoked if the underlying instance/ref changed. If the ref callback itself changed, most likely this just means it's an arrow functions and has an identical implementation.
createRef
would be more problematic, but it is only expected to be created once in the first place, so in practice shouldn't be a problem.
Maybe we should just add an inline comment saying this is technically possible but probably not a concern in practice?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the ref callback itself changed, most likely this just means it's an arrow functions and has an identical implementation.
I don’t think we can rely on something like this. Otherwise we might as well never update refs.
We handled this correctly so far so I don’t think we should regress in this particular case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to write a contrived test to catch the case we're talking about, and it looks like I was mistaken to begin with. Even if props are shallowly equal, the memoizedProps
and pendingProps
objects themselves won't be equal- so we won't bail out- which side steps the issue I mentioned.
Sorry for the dead end. 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We chatted a bit with @acdlite and he proposed to check against current.ref
. Seems like it wouldn’t hurt but I’ll think about it more tomorrow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's interesting how a ref owned by Foo
can change without a subsequent did-update lifecycle being called on Foo
(but that isn't new from this PR, and was also already the case for refs "forwarded" via props
so maybe it's fine).
ReactDOM: size: 🔺+0.1%, gzip: 🔺+0.1% Details of bundled changes.Comparing: 9c77ffb...60ddc00 react-dom
react-art
react-test-renderer
react-reconciler
react-native-renderer
Generated by 🚫 dangerJS |
if (hasLegacyContextChanged()) { | ||
// Normally we can bail out on props equality but if context has changed | ||
// we don't do the bailout and we have to reuse existing props instead. | ||
} else if (workInProgress.memoizedProps === nextProps) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried to write a contrived test to catch the case we're talking about, and it looks like I was mistaken to begin with. Even if props are shallowly equal, the memoizedProps
and pendingProps
objects themselves won't be equal- so we won't bail out- which side steps the issue I mentioned.
Sorry for the dead end. 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Compare workInProgress.ref
to current.ref
as discussed offline
Cool! Agreed it wouldn't hurt, although I can't think of a case where it would currently matter. |
❤️ awesome fix! When will a new version be released? |
Hopefully soon |
Great! just encountered this bug where my "middle" component renders for unknown reasons after adding forwardRef |
Should be fixed in React 16.4. |
20: Update react monorepo to v16.4.0 r=renovate[bot] a=renovate[bot] This Pull Request renovates the package group "react monorepo". - [react-dom](https://github.com/facebook/react) (`dependencies`): from `16.3.2` to `16.4.0` - [react](https://github.com/facebook/react) (`dependencies`): from `16.3.2` to `16.4.0` # Release Notes <details> <summary>facebook/react</summary> ### [`v16.4.0`](https://github.com/facebook/react/blob/master/CHANGELOG.md#​1640-May-23-2018) [Compare Source](facebook/react@8e5f12c...v16.4.0) ##### React * Add a new [experimental](`https://github.com/reactjs/rfcs/pull/51`) `React.unstable_Profiler` component for measuring performance. ([@​bvaughn] in [#​12745](`https://github.com/facebook/react/pull/12745`)) ##### React DOM * Add support for the Pointer Events specification. ([@​philipp-spiess] in [#​12507](`https://github.com/facebook/react/pull/12507`)) * Properly call `getDerivedStateFromProps()` regardless of the reason for re-rendering. ([@​acdlite] in [#​12600](`https://github.com/facebook/react/pull/12600`) and [#​12802](`https://github.com/facebook/react/pull/12802`)) * Fix a bug that prevented context propagation in some cases. ([@​gaearon] in [#​12708](`https://github.com/facebook/react/pull/12708`)) * Fix re-rendering of components using `forwardRef()` on a deeper `setState()`. ([@​gaearon] in [#​12690](`https://github.com/facebook/react/pull/12690`)) * Fix some attributes incorrectly getting removed from custom element nodes. ([@​airamrguez] in [#​12702](`https://github.com/facebook/react/pull/12702`)) * Fix context providers to not bail out on children if there's a legacy context provider above. ([@​gaearon] in [#​12586](`https://github.com/facebook/react/pull/12586`)) * Add the ability to specify `propTypes` on a context provider component. ([@​nicolevy] in [#​12658](`https://github.com/facebook/react/pull/12658`)) * Fix a false positive warning when using `react-lifecycles-compat` in `<StrictMode>`. ([@​bvaughn] in [#​12644](`https://github.com/facebook/react/pull/12644`)) * Warn when the `forwardRef()` render function has `propTypes` or `defaultProps`. ([@​bvaughn] in [#​12644](`https://github.com/facebook/react/pull/12644`)) * Improve how `forwardRef()` and context consumers are displayed in the component stack. ([@​sophiebits] in [#​12777](`https://github.com/facebook/react/pull/12777`)) * Change internal event names. This can break third-party packages that rely on React internals in unsupported ways. ([@​philipp-spiess] in [#​12629](`https://github.com/facebook/react/pull/12629`)) ##### React Test Renderer * Fix the `getDerivedStateFromProps()` support to match the new React DOM behavior. ([@​koba04] in [#​12676](`https://github.com/facebook/react/pull/12676`)) * Fix a `testInstance.parent` crash when the parent is a fragment or another special node. ([@​gaearon] in [#​12813](`https://github.com/facebook/react/pull/12813`)) * `forwardRef()` components are now discoverable by the test renderer traversal methods. ([@​gaearon] in [#​12725](`https://github.com/facebook/react/pull/12725`)) * Shallow renderer now ignores `setState()` updaters that return `null` or `undefined`. ([@​koba04] in [#​12756](`https://github.com/facebook/react/pull/12756`)) ##### React ART * Fix reading context provided from the tree managed by React DOM. ([@​acdlite] in [#​12779](`https://github.com/facebook/react/pull/12779`)) ##### React Call Return (Experimental) * This experiment was deleted because it was affecting the bundle size and the API wasn't good enough. It's likely to come back in the future in some other form. ([@​gaearon] in [#​12820](`https://github.com/facebook/react/pull/12820`)) ##### React Reconciler (Experimental) * The [new host config shape](https://github.com/facebook/react/blob/c601f7a64640290af85c9f0e33c78480656b46bc/packages/react-noop-renderer/src/createReactNoop.js#L82-L285) is flat and doesn't use nested objects. ([@​gaearon] in [#​12792](`https://github.com/facebook/react/pull/12792`)) --- </details> --- This PR has been generated by [Renovate Bot](https://renovatebot.com). Co-authored-by: Renovate Bot <[email protected]>
164: Update react monorepo to v16.4.0 r=rehandalal a=renovate[bot] This Pull Request renovates the package group "react monorepo". - [react-dom](https://github.com/facebook/react) (`dependencies`): from `16.3.2` to `16.4.0` - [react](https://github.com/facebook/react) (`dependencies`): from `16.3.2` to `16.4.0` # Release Notes <details> <summary>facebook/react</summary> ### [`v16.4.0`](https://github.com/facebook/react/blob/master/CHANGELOG.md#​1640-May-23-2018) [Compare Source](facebook/react@8e5f12c...v16.4.0) ##### React * Add a new [experimental](`https://github.com/reactjs/rfcs/pull/51`) `React.unstable_Profiler` component for measuring performance. ([@​bvaughn] in [#​12745](`https://github.com/facebook/react/pull/12745`)) ##### React DOM * Add support for the Pointer Events specification. ([@​philipp-spiess] in [#​12507](`https://github.com/facebook/react/pull/12507`)) * Properly call `getDerivedStateFromProps()` regardless of the reason for re-rendering. ([@​acdlite] in [#​12600](`https://github.com/facebook/react/pull/12600`) and [#​12802](`https://github.com/facebook/react/pull/12802`)) * Fix a bug that prevented context propagation in some cases. ([@​gaearon] in [#​12708](`https://github.com/facebook/react/pull/12708`)) * Fix re-rendering of components using `forwardRef()` on a deeper `setState()`. ([@​gaearon] in [#​12690](`https://github.com/facebook/react/pull/12690`)) * Fix some attributes incorrectly getting removed from custom element nodes. ([@​airamrguez] in [#​12702](`https://github.com/facebook/react/pull/12702`)) * Fix context providers to not bail out on children if there's a legacy context provider above. ([@​gaearon] in [#​12586](`https://github.com/facebook/react/pull/12586`)) * Add the ability to specify `propTypes` on a context provider component. ([@​nicolevy] in [#​12658](`https://github.com/facebook/react/pull/12658`)) * Fix a false positive warning when using `react-lifecycles-compat` in `<StrictMode>`. ([@​bvaughn] in [#​12644](`https://github.com/facebook/react/pull/12644`)) * Warn when the `forwardRef()` render function has `propTypes` or `defaultProps`. ([@​bvaughn] in [#​12644](`https://github.com/facebook/react/pull/12644`)) * Improve how `forwardRef()` and context consumers are displayed in the component stack. ([@​sophiebits] in [#​12777](`https://github.com/facebook/react/pull/12777`)) * Change internal event names. This can break third-party packages that rely on React internals in unsupported ways. ([@​philipp-spiess] in [#​12629](`https://github.com/facebook/react/pull/12629`)) ##### React Test Renderer * Fix the `getDerivedStateFromProps()` support to match the new React DOM behavior. ([@​koba04] in [#​12676](`https://github.com/facebook/react/pull/12676`)) * Fix a `testInstance.parent` crash when the parent is a fragment or another special node. ([@​gaearon] in [#​12813](`https://github.com/facebook/react/pull/12813`)) * `forwardRef()` components are now discoverable by the test renderer traversal methods. ([@​gaearon] in [#​12725](`https://github.com/facebook/react/pull/12725`)) * Shallow renderer now ignores `setState()` updaters that return `null` or `undefined`. ([@​koba04] in [#​12756](`https://github.com/facebook/react/pull/12756`)) ##### React ART * Fix reading context provided from the tree managed by React DOM. ([@​acdlite] in [#​12779](`https://github.com/facebook/react/pull/12779`)) ##### React Call Return (Experimental) * This experiment was deleted because it was affecting the bundle size and the API wasn't good enough. It's likely to come back in the future in some other form. ([@​gaearon] in [#​12820](`https://github.com/facebook/react/pull/12820`)) ##### React Reconciler (Experimental) * The [new host config shape](https://github.com/facebook/react/blob/c601f7a64640290af85c9f0e33c78480656b46bc/packages/react-noop-renderer/src/createReactNoop.js#L82-L285) is flat and doesn't use nested objects. ([@​gaearon] in [#​12792](`https://github.com/facebook/react/pull/12792`)) --- </details> --- This PR has been generated by [Renovate Bot](https://renovatebot.com). Co-authored-by: Renovate Bot <[email protected]>
Woot woot @gaearon |
Fixes #12688. This is not just related to legacy context: as far as I can tell from the test I added, we're currently re-rendering all
forwardRef
components on a deepersetState
. This seems bad.I changed memoization to store the
props
instead of the returned child. Not sure if it matters. Maybe for DevTools?I'm also not sure if what I'm doing here is safe. Can
ref
provided by React ever be different in this scenario and "justify" re-render?