Reset lastEffect when resuming SuspenseList #18412
Conversation
facebook-github-bot
added
React Core Team
|
This pull request is automatically built and testable in CodeSandbox. To see build info of the built libraries, click here or the icon next to each commit SHA. Latest deployment of this branch, based on commit a86b002:
|
We store an effect pointer so we can backtrack in the effect list in some cases. This is a stateful variable. If we interrupt a render we need to reset it. This field was added after the optimization was added and I didn't remember to reset it here. Otherwise we end up not resetting the firstEffect so it points to a stale list. As a result children don't end up inserted like we think they were. Then we try to remove them it errors. It would be nicer to just get rid of the effect list and use the tree for effects instead. Maybe we still need something for deletions tho.
sebmarkbage
force-pushed
the
fixsuspenselistbug
branch
from
00c5575
to
a86b002
Compare
| () => updateHighPri(true), | ||
| ); | ||
|
|
||
| // That will intercept the previous render. |
| // First attempt at high pri. | ||
| 'Suspend! [A]', | ||
| 'Loading A', | ||
| // Re-render at forced. |
There was a problem hiding this comment.
What does "forced" mean here? Which branch does it correspond to? Explain like I'm five.
There was a problem hiding this comment.
SuspenseList sets the suspense context that during render “forces” the suspense boundary into fallback state.
In this case it’s only one boundary so it doesn’t need to but we don’t know. If there was another boundary in the row we would have to rerender that one so that’s the second pass.
There was a problem hiding this comment.
Ohh that makes sense! I didn’t realize it works this way.
| // Re-render at forced. | ||
| 'Suspend! [A]', | ||
| 'Loading A', | ||
| // We auto-commit this on DEV. |
There was a problem hiding this comment.
Why? "Flush fallbacks" flag?
| 'Suspend! [A]', | ||
| 'Loading A', | ||
| ] | ||
| : [ |
There was a problem hiding this comment.
This test is verifying the same logs appear three or four times. But how do we know the comments are actually telling the truth? Can we include the boolean values in logs so that we know we're actually rendering at the priority suggested by comments?
There was a problem hiding this comment.
I’d rather just delete this assertion. It’s unrelated. It’s just that Scheduler expects force me to assert. This is super suboptimal so it’ll change by heuristics a lot.
We store an effect pointer so we can backtrack in the effect list in some cases. This is a stateful variable. If we interrupt a render we need to reset it.
This field was added after the optimization was added and I didn't remember to reset it here.
Otherwise we end up not resetting the firstEffect so it points to a stale list. As a result children don't end up inserted like we think they were. Then we try to remove them it errors.
It would be nicer to just get rid of the effect list and use the tree for effects instead. Maybe we still need something for deletions tho.