-
Notifications
You must be signed in to change notification settings - Fork 49.1k
[Fiber] Treat unwrapping React.lazy more like a use() #34031
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
// pre-warming | ||
'Foo', | ||
]); | ||
assertLog(['Foo']); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Now a Lazy gets to participate in the optimization when it can be immediately resolved in place instead of causing a rerender.
This doesn't have any of the other legacy quirks like infinite pinging concerns since these are unconditionally rendered in the child position and never inside a component render.
Comparing: 71236c9...8aeaef0 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) |
32487cd
to
8aeaef0
Compare
This seems somewhat related to my bug with lazy children in |
While we want to get rid of React.lazy's special wrapper type and just use a Promise for the type, we still have the wrapper. However, this is still conceptually the same as a Usable in that it should be have the same if you `use(promise)` or render a Promise as a child or type position. This PR makes it behave like a `use()` when we unwrap them. We could move to a model where it actually reaches the internal of the Lazy's Promise when it unwraps but for now I leave the lazy API signature intact by just catching the Promise and then "use()" that. This lets us align on the semantics with `use()` such as the suspense yield optimization. It also lets us warn or fork based on legacy throw-a-Promise behavior where as `React.lazy` is not deprecated. DiffTrain build for [9be531c](9be531c)
While we want to get rid of React.lazy's special wrapper type and just use a Promise for the type, we still have the wrapper. However, this is still conceptually the same as a Usable in that it should be have the same if you `use(promise)` or render a Promise as a child or type position. This PR makes it behave like a `use()` when we unwrap them. We could move to a model where it actually reaches the internal of the Lazy's Promise when it unwraps but for now I leave the lazy API signature intact by just catching the Promise and then "use()" that. This lets us align on the semantics with `use()` such as the suspense yield optimization. It also lets us warn or fork based on legacy throw-a-Promise behavior where as `React.lazy` is not deprecated. DiffTrain build for [9be531c](9be531c)
While we want to get rid of React.lazy's special wrapper type and just use a Promise for the type, we still have the wrapper.
However, this is still conceptually the same as a Usable in that it should be have the same if you
use(promise)
or render a Promise as a child or type position.This PR makes it behave like a
use()
when we unwrap them. We could move to a model where it actually reaches the internal of the Lazy's Promise when it unwraps but for now I leave the lazy API signature intact by just catching the Promise and then "use()" that.This lets us align on the semantics with
use()
such as the suspense yield optimization. It also lets us warn or fork based on legacy throw-a-Promise behavior where asReact.lazy
is not deprecated.