-
Notifications
You must be signed in to change notification settings - Fork 47k
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
React.unstable_AsyncComponent #10239
Conversation
Should this be |
I imagine people would conflate it with class MyComponent extends React.AsyncComponent {...} or is that what you meant? |
We could call it |
It's not that bad if they do use the inheritance. They could use either. |
True but that prevents us in the future from changing this from a class to something else. |
But I guess that's not that important. I do like the symmetry with the other component exports. |
It also solves the problem of the return value of |
Clever! Ok you've convinced me |
There is a problem using static flags though. We didn't do that for |
It should probably also be an object instead of boolean. We did that because jest automocking sometimes screwed up the mocking the boolean as undefined. I'm not sure if that's a big problem anymore but could be. |
Interesting... ok. Is there a reason we originally went with a static flag for |
There is no special syntax for adding a flag to a prototype (other than methods) and it's inefficient to add it to every instance instead of shared on the prototype. That's solved by the base class model. |
src/isomorphic/ReactAsyncWrapper.js
Outdated
|
||
const ReactBaseClasses = require('ReactBaseClasses'); | ||
|
||
class ReactAsyncWrapper extends ReactBaseClasses.Component { |
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.
Can we go with very minimal function
prototype thing rather than Babel class output? We’ve tried very hard to trim down isomorphic React package, class output was a bit bloated last I checked.
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.
About to push a commit that does this the same way as PureComponent
913c82c
to
8fd95a2
Compare
this.updater = updater || ReactNoopUpdateQueue; | ||
} | ||
|
||
function ComponentDummy2() {} |
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.
Can we reuse the dummy function from above? Not sure if that is worth from an optimization perspective or not.
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.
Fixed
f92982f
to
229195b
Compare
this.updater = updater || ReactNoopUpdateQueue; | ||
} | ||
|
||
ReactAsyncComponent.prototype = new ComponentDummy(); |
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.
Might be worth adding a variable here. var ReactAsyncComponentPrototype =
here so that you can use that instead of rereading the prototype below. Save a few bytes.
ReactAsyncComponent.prototype.constructor = ReactAsyncComponent; | ||
// Avoid an extra prototype jump for these methods. | ||
Object.assign(ReactAsyncComponent.prototype, ReactComponent.prototype); | ||
ReactAsyncComponent.prototype.unstable_isAsyncReactComponent = true; |
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.
Should we do = {}
just like isReactComponent
does?
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.
I did it the same as PureComponent
. I don't have all the context for why this is important, but if it is, we should do it for PureComponent
as well.
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.
Interesting. It might not be noticeable for PureComponent because nobody relies on shouldComponentUpdate for behavior.
However, worst case, I guess this just triggers sync mode.
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.
Oh right, the Jest thing. Yeah, funny that the "worst case" in this situation is exactly what we'd want it to be, anyway, per our recent discussion. :D
Alternative to using the static class property unstable_asyncUpdates. Everything inside <AsyncComponent /> has async updates by default. You can also extend it like PureComponent or Component.
229195b
to
cd071a9
Compare
@acdlite I can use this feature by modifying the flag in |
I've missed that the flag is already I've misunderstood I tried to wrap some heavy components(many list components) by <div>
<Other />
<AsyncComponent>
<HeavyList />
</AsyncComponent>
</div> |
I thinks maybe that's because above flag is react/src/renderers/shared/fiber/ReactFiberReconciler.js Lines 225 to 233 in c55ffb3
It seems that just enableAsyncSubtreeAPI is
And IIRC, async render will be enabled at least react-17, so I am not sure why they plan to do this just now. @acdlite ping~ |
Alternative to using the static class property unstable_asyncUpdates. Everything inside has async updates by default.