Check for Suspense boundary in a root Container#16673
Merged
sebmarkbage merged 1 commit intofacebook:masterfrom Sep 5, 2019
Merged
Check for Suspense boundary in a root Container#16673sebmarkbage merged 1 commit intofacebook:masterfrom
sebmarkbage merged 1 commit intofacebook:masterfrom
Conversation
If we find a Container that might mean that we're on a node that is inside a Suspense boundary that is directly inside the Container root. Imagine the div is a Container and the span is a dehydrated instance: ``` <div> <!--$--> <span /> <!--/$--> </div> ``` There's no way to tests this yet since I'm not actually utilizing the return value yet. The solution is to just use the same path to check for a Suspense boundary as if we find a parent instance.
trueadm
approved these changes
Sep 5, 2019
sebmarkbage
added a commit
to sebmarkbage/react
that referenced
this pull request
Sep 23, 2019
This is a follow up to facebook#16673 which didn't have a test because it wasn't observable yet. This shows that it had a bug.
sebmarkbage
added a commit
to sebmarkbage/react
that referenced
this pull request
Sep 23, 2019
This is a follow up to facebook#16673 which didn't have a test because it wasn't observable yet. This shows that it had a bug.
sebmarkbage
added a commit
that referenced
this pull request
Sep 23, 2019
* Add Event Replaying Infra * Wire up Roots and Suspense boundaries, to retry events, after they commit * Replay discrete events in order in a separate scheduler callback * Add continuous events These events only replay their last target if the target is not yet hydrated. That way we don't have to wait for a previously hovered boundary before invoking the current target. * Enable tests from before These tests were written with replaying in mind and now we can properly enable them. * Unify replaying and dispatching * Mark system flags as a replay and pass to legacy events That way we can check if this is a replay and therefore needs a special case. One such special case is "mouseover" where we check the relatedTarget. * Eagerly listen to all replayable events To minimize breakages in a minor, I only do this for the new root APIs since replaying only matters there anyway. Only if hydrating. For Flare, I have to attach all active listeners since the current system has one DOM listener for each. In a follow up I plan on optimizing that by only attaching one if there's at least one active listener which would allow us to start with only passive and then upgrade. * Desperate attempt to save bytese * Add test for mouseover replaying We need to check if the "relatedTarget" is mounted due to how the old event system dispatches from the "out" event. * Fix for nested boundaries and suspense in root container This is a follow up to #16673 which didn't have a test because it wasn't observable yet. This shows that it had a bug. * Rename RESPONDER_EVENT_SYSTEM to PLUGIN_EVENT_SYSTEM
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
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.
If we find a Container that might mean that we're on a node that is inside
a Suspense boundary that is directly inside the Container root.
Imagine the div is a Container and the span is a dehydrated instance:
There's no way to tests this yet since I'm not actually utilizing
the return value yet.
The solution is to just use the same path to check for a Suspense boundary
as if we find a parent instance.