Deprecate renderToNodeStream (and fix textarea bug) #23359
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
This is the equivalent API. This means that we have way less test coverage of this API but I feel like that's fine since it has a deprecation warning in it and we have coverage on renderToString that is mostly the same.
The test changes revealed a bug with textarea. It happens because we currently always insert trailing comment nodes. We should optimize that away. However, we also don't really support complex children so we should toString it anyway which is what partial renderer used to do.
These tests are unnecessarily specific about number of nodes. I special case these, which these tests already do, because they're good tests to test that the optimization actually works later when we do fix it.
|
Comparing: 8c4cd65...509678d Critical size changesIncludes critical production bundles, as well as any change greater than 2%:
Significant size changesIncludes any change greater than 0.2%: (No significant changes) |
acdlite
approved these changes
Feb 25, 2022
zhengjitf
pushed a commit
to zhengjitf/react
that referenced
this pull request
Apr 15, 2022
* Deprecate renderToNodeStream * Use renderToPipeableStream in tests instead of renderToNodeStream This is the equivalent API. This means that we have way less test coverage of this API but I feel like that's fine since it has a deprecation warning in it and we have coverage on renderToString that is mostly the same. * Fix textarea bug The test changes revealed a bug with textarea. It happens because we currently always insert trailing comment nodes. We should optimize that away. However, we also don't really support complex children so we should toString it anyway which is what partial renderer used to do. * Update tests that assert number of nodes These tests are unnecessarily specific about number of nodes. I special case these, which these tests already do, because they're good tests to test that the optimization actually works later when we do fix it.
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.
This adds a deprecation warning for renderToNodeStream and favors the new renderToPipeableStream.
Notably renderToStaticNodeStream is NOT deprecated yet. That's because the static optimizations are only in the legacy build right now. I don't really want to add that flag to the main line so we should do something special for the e-mail generation use case with a special build. So we don't have an alternative yet. That also means there's no static option for Web Streams.
I switched our integration tests to use renderToPipeableStream. That revealed some breaking tests. All due to the fact that we add trailing comment nodes to any text node. This is pretty clowny and known optimization that we know we need to add back in. The only reason it didn't break before is because the legacy version strips it out at the end.
However, in the case of "textarea" that's actually a bug since that will show up in the textarea's value. So I fixed that bug.