-
Notifications
You must be signed in to change notification settings - Fork 47.4k
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
[RSC @ Meta] Simplify implementation of isClientReference, getClientReferenceKey, resolveClientReferenceMetadata #27839
Conversation
Comparing: 493610f...5f125f9 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
|
The register functions are really meant to move to be more unified between multiple implementations. It might be more obvious when you deal with Server References that has more of that implemented already. Originally this was more up to each config but we realized we started add more and more features to the references themselves. For example we're trying to unify the Proxy implementation so that they can provide the same error messages when you try to access something you shouldn't and that you can create the same indirections. Another feature is that on Server References, we extend But currently the implementation is a bit ambivalent about how strongly React needs to control the reference. |
That's not to say you can't remove the |
Thanks @sebmarkbage! That makes sense, I'll keep the register functions (as noop for now) to keep the public API consistent. |
// eslint-disable-next-line no-unused-vars | ||
export type ServerReference<T> = string; | ||
|
||
// eslint-disable-next-line no-unused-vars |
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.
are the // eslint-disable-next-line no-unused-vars
actually needed?
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.
This is just to keep the same interface across different configurations, these types are using generic T, which is unused in this specific case.
…eferenceKey, resolveClientReferenceMetadata (#27839) For clientReferences we can just check the instance of the `clientReference`. The implementation of `isClientReference` is provided via configuration. The class for ClientReference has to implement an interface that has `getModuleId() method. DiffTrain build for [cb24396](cb24396)
### React upstream changes - facebook/react#27888 - facebook/react#27870 - facebook/react#27871 - facebook/react#27850 - facebook/react#27839 - facebook/react#27842 - facebook/react#27841 - facebook/react#27840 - facebook/react#27761 - facebook/react#27831 - facebook/react#27801 Closes NEXT-2012
…eferenceKey, resolveClientReferenceMetadata (facebook#27839) For clientReferences we can just check the instance of the `clientReference`. The implementation of `isClientReference` is provided via configuration. The class for ClientReference has to implement an interface that has `getModuleId() method.
…eferenceKey, resolveClientReferenceMetadata (#27839) For clientReferences we can just check the instance of the `clientReference`. The implementation of `isClientReference` is provided via configuration. The class for ClientReference has to implement an interface that has `getModuleId() method. DiffTrain build for commit cb24396.
For clientReferences we can just check the instance of the
clientReference
.The implementation of
isClientReference
is provided via configuration. The class for ClientReference has to implement an interface that has `getModuleId() method.