[Fizz] Include a component stack in prod but only lazily generate it #30132
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
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
facebook-github-bot
added
CLA Signed
React Core Team
sebmarkbage
force-pushed
the
lazyfizzstack
branch
from
d102ba7
to
f972645
Compare
|
Comparing: 100dfd7...476f6d0 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
|
sebmarkbage
force-pushed
the
lazyfizzstack
branch
from
f972645
to
476f6d0
Compare
acdlite
approved these changes
Jul 2, 2024
|
Meta can just make sure not to touch this property if a client render happens which I assume is what is done now since it's not used. |
github-actions bot
pushed a commit
that referenced
this pull request
Jul 2, 2024
…30132) When we added component stacks to Fizz in prod it severely slowed down common cases where you intentionally are throwing error for purposes of client rendering. Our parent component stack generation is very slow since call components with fake errors to generate them. Therefore we disabled them in prod but included them in prerenders. #27850 However, we still kept generating data structures for them and the code still exists there for the prerenders. We could stop generating the data structures which are not completely free but also not crazy bad. What we can do instead is just lazily generate the component stacks. This is in fact what plain stacks do anyway. This doesn't work as well in Fiber because the data structures are live but on the server they're immutable so it's fine to do it later as well. That way you can choose to not read this getter for intentionally thrown errors - after inspecting the Error object - yet still get component stacks in prod for other errors. DiffTrain build for [e60063d](e60063d)
sebmarkbage
added a commit
that referenced
this pull request
Jul 2, 2024
Stacked on #30132. This way we can get parent and owner stacks from the error. This forces us to confront multiple errors and whether or not a Flight error that ends up being unobservable needs to really reject the render. This implements stashing of Flight errors with a digest and only errors if they end up erroring the Fizz render too. At this point they'll have parent stacks so we can surface those.
This was referenced Jul 25, 2024
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.
When we added component stacks to Fizz in prod it severely slowed down common cases where you intentionally are throwing error for purposes of client rendering. Our parent component stack generation is very slow since call components with fake errors to generate them.
Therefore we disabled them in prod but included them in prerenders. #27850
However, we still kept generating data structures for them and the code still exists there for the prerenders. We could stop generating the data structures which are not completely free but also not crazy bad.
What we can do instead is just lazily generate the component stacks. This is in fact what plain stacks do anyway. This doesn't work as well in Fiber because the data structures are live but on the server they're immutable so it's fine to do it later as well.
That way you can choose to not read this getter for intentionally thrown errors - after inspecting the Error object - yet still get component stacks in prod for other errors.