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 |
| // 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.
It doesn't seem clear to me if the safelyAttachRef call should be done conditional here.
There was a problem hiding this comment.
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:
|
| commitReconciliationEffects(finishedWork); | ||
|
|
||
| if (flags & Ref) { | ||
| if (flags & Ref && !offscreenSubtreeWasHidden) { |
There was a problem hiding this comment.
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.
@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.
Are you sure about this behavior? We don't check for Offscreen anywhere else that we attach.
There was a problem hiding this comment.
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.
I'm not sure why
ScopeComponentrequiressafelyAttachRefto 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.
~~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.
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.
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 withnullwithout 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 sincesafelyAttachRefwas never called,safelyDetachRefthinks the ref does not return a cleanup function and invokes it withnull).This fix makes use of
offscreenSubtreeWasHiddenincommitDeletionEffectsOnFiber, 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.