[Fizz] Implement Legacy renderToString and renderToNodeStream on top of Fizz #21276
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
facebook-github-bot
added
CLA Signed
React Core Team
|
Comparing: 1a106bd...c24b569 Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: Expand to show
|
Merged
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
The way this set up works, the stable tests doesn't actually run against stable because jest doesn't use the entry point override thing. That's only set up for builds. Tests against builds run against stable though. But basically because of this, I can't use the test gating feature. The other issue is that I want to expose both this legacy build and unstable-fizz on a single module entry point with different export names. Because when migrating you shouldn't need to migrate to a new name and then back later. But the way tests fork the host config, is based on the entry point so that whole thing doesn't work. So we'll need to put some significant build/test infra work in to land this. |
sebmarkbage
force-pushed
the
fizzlegacy
branch
2 times, most recently
from
6fdc530
to
fd89f83
Compare
sebmarkbage
force-pushed
the
fizzlegacy
branch
3 times, most recently
from
02bdd0c
to
d979668
Compare
I think this might be faster. We could probably use a combination of this technique in the stream too to lower the overhead.
Maybe this should always error but in the async forms we can just delay the stream until it resolves so it does have some useful semantics. In the synchronous form it's never useful though. I'm mostly adding the error because we're testing this behavior for renderToString specifically.
sebmarkbage
changed the title
sebmarkbage
force-pushed
the
fizzlegacy
branch
2 times, most recently
from
c01c3fb
to
199943e
Compare
These tests don't translate as is to the new implementation and have been ported to the Fizz tests separately.
This ensures that we can inject custom overrides without negatively affecting the new implementation. This adds another field for static mark up for example.
Completed and client rendered boundaries are only marked for the client to take over. Pending boundaries are still supported in case you stream non-hydratable mark up.
sebmarkbage
force-pushed
the
fizzlegacy
branch
2 times, most recently
from
672dd7f
to
1b72b75
Compare
This shouldn't affect the FB one ideally but it's done with the same build so let's hope this works.
koto
pushed a commit
to koto/react
that referenced
this pull request
Jun 15, 2021
…of Fizz (facebook#21276) * Wire up DOM legacy build * Hack to filter extra comments for testing purposes * Use string concat in renderToString I think this might be faster. We could probably use a combination of this technique in the stream too to lower the overhead. * Error if we can't complete the root synchronously Maybe this should always error but in the async forms we can just delay the stream until it resolves so it does have some useful semantics. In the synchronous form it's never useful though. I'm mostly adding the error because we're testing this behavior for renderToString specifically. * Gate memory leak tests of internals These tests don't translate as is to the new implementation and have been ported to the Fizz tests separately. * Enable Fizz legacy mode in stable * Add wrapper around the ServerFormatConfig for legacy mode This ensures that we can inject custom overrides without negatively affecting the new implementation. This adds another field for static mark up for example. * Wrap pushTextInstance to avoid emitting comments for text in static markup * Don't emit static mark up for completed suspense boundaries Completed and client rendered boundaries are only marked for the client to take over. Pending boundaries are still supported in case you stream non-hydratable mark up. * Wire up generateStaticMarkup to static API entry points * Mark as renderer for stable This shouldn't affect the FB one ideally but it's done with the same build so let's hope this works.
facebook-github-bot
pushed a commit
to facebook/react-native
that referenced
this pull request
Jun 22, 2021
Summary: This sync includes the following changes: - **[43f4cc160](facebook/react@43f4cc160 )**: Fix failing test ([#21697](facebook/react#21697)) //<Dan Abramov>// - **[d0f348dc1](facebook/react@d0f348dc1 )**: Fix for failed Suspense layout semantics ([#21694](facebook/react#21694)) //<Brian Vaughn>// - **[bd0a96344](facebook/react@bd0a96344 )**: Throw when `act` is used in production ([#21686](facebook/react#21686)) //<Andrew Clark>// - **[9343f8720](facebook/react@9343f8720 )**: Use the server src files as entry points for the builds/tests ([#21683](facebook/react#21683)) //<Sebastian Markbåge>// - **[502f8a2a0](facebook/react@502f8a2a0 )**: [Fizz/Flight] Don't use default args ([#21681](facebook/react#21681)) //<Sebastian Markbåge>// - **[a8f5e77b9](facebook/react@a8f5e77b9 )**: Remove invokeGuardedCallback from commit phase ([#21666](facebook/react#21666)) //<Dan Abramov>// - **[dbe3363cc](facebook/react@dbe3363cc )**: [Fizz] Implement Legacy renderToString and renderToNodeStream on top of Fizz ([#21276](facebook/react#21276)) //<Sebastian Markbåge>// - **[101ea9f55](facebook/react@101ea9f55 )**: Set deletedTreeCleanUpLevel to 3 ([#21679](facebook/react#21679)) //<Dan Abramov>// - **[1a106bdc2](facebook/react@1a106bdc2 )**: Wrap eventhandle-specific logic in a flag ([#21657](facebook/react#21657)) //<Dan Abramov>// - **[cb30388d1](facebook/react@cb30388d1 )**: Export React Native `AttributeType` Types ([#21661](facebook/react#21661)) //<Timothy Yung>// - **[c1536795c](facebook/react@c1536795c )**: Revert "Make enableSuspenseLayoutEffectSemantics static for www ([#21617](facebook/react#21617))" ([#21656](facebook/react#21656)) //<Sebastian Markbåge>// Changelog: [General][Changed] - React Native sync for revisions c96b78e...568dc35 jest_e2e[run_all_tests] Reviewed By: rickhanlonii Differential Revision: D29303157 fbshipit-source-id: 90952885eb2264f4effa04070357b80700bb9be3
|
Hey @sebmarkbage, I have questions about Currently, I am trying to use cloudflare worker to do the SSR rendering. I have my own webpack plugin to build the js for cloudflare worker to run. My own plugin currently needs to specify the fallback for two dependencies If |
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.
I use a separate build from the main Fizz build because it uses a slightly different configuration. This adds a custom StreamConfig that only uses strings and pushes to a readable-like API.
I enabled the new builds in experimental/modern.
This variant of Fizz uses an infinite progressiveChunkSize and it always waits until everything is completed until starting to write. The effect of this is that the output should never include any scripts and always just render HTML.
Suspending works in both but renderToString switches to client rendering for those cases. renderToNodeStream waits to start writing anything to the stream until they all resolve.
renderToNodeStream will have very different performance characteristics because this new variant will eagerly build up as much HTML as possible as aggressively as possible. This is the new strategy we're going after. If that's not good, then adding more suspense breaks it up. This API should be deprecated and switching to the Fizz model is preferred. While the previous approach of renderToNodeStream is somewhat valid, it's not inline with the future strategy so I don't plan on having a true replacement for CPU throttled. Instead, we could use some level of time slicing at suspense boundary levels in the full Fizz.
This now uses a wrapper around the FormatConfig. This allows us to do custom overrides of the HTML for legacy purposes. This also supports static markup generation (not hydratable HTML). Static mark up isn't legacy per se but the newer version might use something like an optimization of Server Components rather than its own mode. For now, renderToStaticMarkup and renderToStaticNodeStream mode is supported.