-
Notifications
You must be signed in to change notification settings - Fork 47.1k
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
Fix Ref Lifecycles in Hidden Subtrees #31379
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
By the way, I don't add these checks to the |
@@ -2073,7 +2077,7 @@ function commitMutationEffectsOnFiber( | |||
|
|||
// TODO: This is a temporary solution that allowed us to transition away | |||
// from React Flare on www. | |||
if (flags & Ref) { | |||
if (flags & Ref && !offscreenSubtreeWasHidden) { |
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 doesn't seem clear to me if the safelyAttachRef
call should be done conditional here.
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.
Conceptually, it makes sense to skip both. I'm not sure why Scope
refs are even being attached here in the first place. 😕
I believe this is a good approach to fix it. Could you explain in the PR description why offscreenSubtreeWasHidden is the right choice here? |
@sammy-SC Added this to the PR summary:
|
@@ -1744,7 +1748,7 @@ function commitMutationEffectsOnFiber( | |||
recursivelyTraverseMutationEffects(root, finishedWork, lanes); | |||
commitReconciliationEffects(finishedWork); | |||
|
|||
if (flags & Ref) { | |||
if (flags & Ref && !offscreenSubtreeWasHidden) { |
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.
For the Jest unit test that @rickhanlonii added in a2c9e7a, this is the only line that is actually necessary to fix the unit test.
if (!offscreenSubtreeWasHidden && current !== null) { | ||
safelyDetachRef(finishedWork, finishedWork.return); | ||
} | ||
safelyAttachRef(finishedWork, finishedWork.return); | ||
if (!offscreenSubtreeIsHidden) { | ||
safelyAttachRef(finishedWork, finishedWork.return); | ||
} |
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.
@kassens, I think this is the correct behavior.
You were right that !offscreenSubtreeWasHidden
should only be scoped to safelyDetachRef
, and we were missing a !offscreenSubtreeIsHidden
check around safelyAttachRef
.
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.
Are you sure about this behavior? We don't check for Offscreen anywhere else that we attach.
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 don't check for Offscreen anywhere else that we attach.
We actually do, but it's implicit.
Every other type calls safelyAttachRef
from reappearLayoutEffects
, which is called only by recursivelyTraverseReappearLayoutEffects
. These occur during:
In both of these, we prune traversal when we encounter a hidden Offscreen
. (See the links above for where this happens.)
Are you sure about this behavior?
I'm not sure why ScopeComponent
requires safelyAttachRef
to be here, but I assume it has something to do with the comment above:
// TODO: This is a temporary solution that allowed us to transition away
// from React Flare on www.
I don't plan to change this as part of fixing refs, though. I considered an alternative in which I leave ScopeComponent
alone, but I think this is actually the correct fix.
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'm not sure why
ScopeComponent
requiressafelyAttachRef
to be here, [...]
I traced the origin of that comment (which was harder than I expected due to the reconciler forking and unforking that happened) and found this: #19264
To unblock internal progression on replacing React Flare, let's instead move resolution of Scope API refs to the mutation phase, so we can attach event listeners to scopes before the layout phase begins.
I don't fully understand the context, but I figured that it would be helpful to know its origin.
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.
~~After writing unit tests for this bug, I've confirmed that these changes are actually not needed to prevent <Scope ref={X}>
from invoking X
in <Activity mode="hidden">
.
I've dropped these changes for now.~~
Oh… just kidding, I was not running yarn test
with -r=www-classic
(which is where enableScopeAPI
is enabled). These changes are needed after all, will update.
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 confirmed that Scope
was previously completely ignoring any parent Activity
that declared the subtree as hidden.
a21f919
to
1b7c7ee
Compare
if (!offscreenSubtreeWasHidden) { | ||
safelyDetachRef(deletedFiber, nearestMountedAncestor); | ||
} |
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.
In the unit test for "ignores ref for Activity in hidden subtree", I discovered that this and the call from commitMutationEffectsOnFiber
are triggered, causing X
to be incorrectly invoked twice! 🤯
<Activity mode="hidden">
<Activity mode="visible" ref={X}>
<div />
</Activity>
</Activity>
I've expanded on the unit tests and verified that 1) each new test fails without this PR, and 2) each line modified by this PR (except for that one comment misspelling) is necessary for one of the new tests to succeed. |
## Summary We're seeing certain situations in React Native development where ref callbacks in `<Activity mode="hidden">` are sometimes invoked exactly once with `null` without ever being called with a "current" value. This violates the contract for refs because refs are expected to always attach before detach (and to always eventually detach after attach). This is *particularly* bad for refs that return cleanup functions, because refs that return cleanup functions expect to never be invoked with `null`. This bug causes such refs to be invoked with `null` (because since `safelyAttachRef` was never called, `safelyDetachRef` thinks the ref does not return a cleanup function and invokes it with `null`). This fix makes use of `offscreenSubtreeWasHidden` in `commitDeletionEffectsOnFiber`, similar to how ec52a56 did this for `commitDeletionEffectsOnFiber`. ## How did you test this change? We were able to isolate the repro steps to isolate the React Native experimental changes. However, the repro steps depend on Fast Refresh. ``` function callbackRef(current) { // Called once with `current` as null, upon triggering Fast Refresh. } <Activity mode="hidden"> <View ref={callbackRef} />; </Activity> ``` Ideally, we would have a unit test that verifies this behavior without Fast Refresh. (We have evidence that this bug occurs without Fast Refresh in real product implementations. However, we have not successfully deduced the root cause, yet.) This PR currently includes a unit test that reproduces the Fast Refresh scenario, which is also demonstrated in this CodeSandbox: https://codesandbox.io/p/sandbox/hungry-darkness-33wxy7 Verified unit tests pass: ``` $ yarn $ yarn test # Run with `-r=www-classic` for `enableScopeAPI` tests. $ yarn test -r=www-classic ``` Verified on the internal React Native development branch that the bug no longer repros. --------- Co-authored-by: Rick Hanlon <rickhanlonii@fb.com> DiffTrain build for [ea3ac58](ea3ac58)
## Summary We're seeing certain situations in React Native development where ref callbacks in `<Activity mode="hidden">` are sometimes invoked exactly once with `null` without ever being called with a "current" value. This violates the contract for refs because refs are expected to always attach before detach (and to always eventually detach after attach). This is *particularly* bad for refs that return cleanup functions, because refs that return cleanup functions expect to never be invoked with `null`. This bug causes such refs to be invoked with `null` (because since `safelyAttachRef` was never called, `safelyDetachRef` thinks the ref does not return a cleanup function and invokes it with `null`). This fix makes use of `offscreenSubtreeWasHidden` in `commitDeletionEffectsOnFiber`, similar to how ec52a56 did this for `commitDeletionEffectsOnFiber`. ## How did you test this change? We were able to isolate the repro steps to isolate the React Native experimental changes. However, the repro steps depend on Fast Refresh. ``` function callbackRef(current) { // Called once with `current` as null, upon triggering Fast Refresh. } <Activity mode="hidden"> <View ref={callbackRef} />; </Activity> ``` Ideally, we would have a unit test that verifies this behavior without Fast Refresh. (We have evidence that this bug occurs without Fast Refresh in real product implementations. However, we have not successfully deduced the root cause, yet.) This PR currently includes a unit test that reproduces the Fast Refresh scenario, which is also demonstrated in this CodeSandbox: https://codesandbox.io/p/sandbox/hungry-darkness-33wxy7 Verified unit tests pass: ``` $ yarn $ yarn test # Run with `-r=www-classic` for `enableScopeAPI` tests. $ yarn test -r=www-classic ``` Verified on the internal React Native development branch that the bug no longer repros. --------- Co-authored-by: Rick Hanlon <rickhanlonii@fb.com> DiffTrain build for [ea3ac58](ea3ac58)
## Summary While fixing ref lifecycles in hidden subtrees in #31379, @rickhanlonii noticed that we could also add more unit tests for other types of tags to prevent future regressions during code refactors. This PR adds more unit tests in the same vein as those added in #31379. ## How did you test this change? Verified unit tests pass: ``` $ yarn $ yarn test ReactFreshIntegration-test.js ```
In the unit test for "ignores ref for Activity in hidden subtree", I discovered that this *and* the call from `commitMutationEffectsOnFiber` are triggered, causing `X` to be incorrectly invoked *twice*! 🤯 ``` <Activity mode="hidden"> <Activity mode="visible" ref={X}> <div /> </Activity> </Activity> ``` _Originally posted by @yungsters in facebook/react#31379 (comment)
Summary
We're seeing certain situations in React Native development where ref callbacks in
<Activity mode="hidden">
are sometimes invoked exactly once withnull
without ever being called with a "current" value.This violates the contract for refs because refs are expected to always attach before detach (and to always eventually detach after attach). This is particularly bad for refs that return cleanup functions, because refs that return cleanup functions expect to never be invoked with
null
. This bug causes such refs to be invoked withnull
(because sincesafelyAttachRef
was never called,safelyDetachRef
thinks the ref does not return a cleanup function and invokes it withnull
).This fix makes use of
offscreenSubtreeWasHidden
incommitDeletionEffectsOnFiber
, similar to how ec52a56 did this forcommitDeletionEffectsOnFiber
.How did you test this change?
We were able to isolate the repro steps to isolate the React Native experimental changes. However, the repro steps depend on Fast Refresh.
Ideally, we would have a unit test that verifies this behavior without Fast Refresh. (We have evidence that this bug occurs without Fast Refresh in real product implementations. However, we have not successfully deduced the root cause, yet.)
This PR currently includes a unit test that reproduces the Fast Refresh scenario, which is also demonstrated in this CodeSandbox: https://codesandbox.io/p/sandbox/hungry-darkness-33wxy7
Verified unit tests pass:
Verified on the internal React Native development branch that the bug no longer repros.