Deal with fallback content in Partial Hydration #14884
Merged
Conversation
This file contains 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
|
ReactDOM: size: 0.0%, gzip: 0.0% Details of bundled changes.Comparing: 0e67969...6d626fb react-dom
react-art
react-native-renderer
react-test-renderer
react-reconciler
Generated by 🚫 dangerJS |
This introduces three states for dehydrated suspense boundaries Pending - This means that the tree is still waiting for additional data or to be populated with its final content. Fallback - This means that the tree has entered a permanent fallback state and no more data from the server is to be expected. This means that the client should take over and try to render instead. The fallback nodes will be deleted. Normal - The node has entered its final content and is now ready to be hydrated.
This doesn't just retry. It assumes that resolving a thenable means that it is ok to clear it from the thenable cache. We'll reuse the retryTimedOutBoundary logic separately.
…ding It's now possible to switch from a pending state to either hydrating or replacing the content.
sebmarkbage
force-pushed
the
partialhydration
branch
from
d5cbef5
to
6d626fb
Compare
acdlite
approved these changes
Feb 19, 2019
This was referenced Mar 2, 2019
This was referenced Apr 20, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Previously we assumed that we hydrated only once we had the final content in the suspense boundary. This lets a dehydrated suspense boundary to be in three possible states (as encoded with different comment nodes):
Pending
<!--$?-->- In the pending state, we assume that the content is displaying the fallback state and we're not yet to hydrate because the streaming server (Fizz) will send the content later on. In this state, React won't try to hydrate the content. If props or context changes, the boundary will be deleted and replaced. React will register a._reactRetryfunction on the comment node which is expected to be invoked when this boundary changes to one of the other two states.Fallback
<!--$!-->- In the fallback state, we assume that the content is displaying the fallback state and that it is fine to keep displaying that but we won't get anything more from the server. Therefore, React is now free to replace it with the final content by rendering it on the client instead.Success
<!--$-->- In this state, we assume that the content of the boundary is the final content and will be the same as if we rendered the content on the client so we can now start hydrating it.In the current server renderer we always render suspended boundaries as "Fallback". This is useful for content that you only want to render on the client.
In Fizz, this PR lets hydration start before the final content is resolved.
It is possible that the server will eventually error and not be able to send the final content. If that happens, or a timeout, the Fizz runtime is expected to switch the pending state to fallback state. This lets the client try to render it, and if it errors again, replace it with error boundary content.
I had thought that we could always try to render the content on the client if we could. However, that didn't work out. For one, it's a waste of cycles since you're most likely going to suspend anyway since you're unlikely to have all the data sent down the wire yet. More importantly, if the client succeeds, it might still have further nested fallback states that the server wouldn't have had. So it might be better to show the server content anyway. In theory we could try to patch up new server content but that seems complicated and breaks the clean architectural boundary between Fizz and the client.