-
Notifications
You must be signed in to change notification settings - Fork 24.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
Generate RCTThirdPartyComponentProvider #47518
Conversation
This pull request was exported from Phabricator. Differential Revision: D65614347 |
Summary: This change reintroduce the generation of the `RCTThirdPartyComponentProvider` but in the right place and with the right patterns. 1. We are generating it in the user space, not in the node_modules (fixes the circular dependency) 2. We are not using weak function signature that have to be implicitly linked to some symbols found during compilation The change needs to crawl the folder to retrieve the information it needs. We need to implement it this way not to be breaking with respect of the current implementation. The assumption is that components have a function in their `.mm` file with this shape: ```objc Class<RCTComponentViewProtocol> <componentName>Cls(void) { return <ComponentViewClass>.class; } ``` I verified on GH that all the libraries out there follow this pattern. A better approach will let library owner to specify the association of `componentName, componentClass` in the `codegenConfig`. We will implement that as the next step and we will support both for some versions for backward compatibility. ## Changelog [iOS][Changed] - Change how components automatically register Differential Revision: D65614347
5245481
to
9b9a5d5
Compare
This pull request was exported from Phabricator. Differential Revision: D65614347 |
Summary: This change reintroduce the generation of the `RCTThirdPartyComponentProvider` but in the right place and with the right patterns. 1. We are generating it in the user space, not in the node_modules (fixes the circular dependency) 2. We are not using weak function signature that have to be implicitly linked to some symbols found during compilation The change needs to crawl the folder to retrieve the information it needs. We need to implement it this way not to be breaking with respect of the current implementation. The assumption is that components have a function in their `.mm` file with this shape: ```objc Class<RCTComponentViewProtocol> <componentName>Cls(void) { return <ComponentViewClass>.class; } ``` I verified on GH that all the libraries out there follow this pattern. A better approach will let library owner to specify the association of `componentName, componentClass` in the `codegenConfig`. We will implement that as the next step and we will support both for some versions for backward compatibility. ## Changelog [iOS][Changed] - Change how components automatically register Differential Revision: D65614347
Summary: This change reintroduce the generation of the `RCTThirdPartyComponentProvider` but in the right place and with the right patterns. 1. We are generating it in the user space, not in the node_modules (fixes the circular dependency) 2. We are not using weak function signature that have to be implicitly linked to some symbols found during compilation The change needs to crawl the folder to retrieve the information it needs. We need to implement it this way not to be breaking with respect of the current implementation. The assumption is that components have a function in their `.mm` file with this shape: ```objc Class<RCTComponentViewProtocol> <componentName>Cls(void) { return <ComponentViewClass>.class; } ``` I verified on GH that all the libraries out there follow this pattern. A better approach will let library owner to specify the association of `componentName, componentClass` in the `codegenConfig`. We will implement that as the next step and we will support both for some versions for backward compatibility. ## Changelog [iOS][Changed] - Change how components automatically register Differential Revision: D65614347
9b9a5d5
to
d1e00ed
Compare
Summary: This change reintroduce the generation of the `RCTThirdPartyComponentProvider` but in the right place and with the right patterns. 1. We are generating it in the user space, not in the node_modules (fixes the circular dependency) 2. We are not using weak function signature that have to be implicitly linked to some symbols found during compilation The change needs to crawl the folder to retrieve the information it needs. We need to implement it this way not to be breaking with respect of the current implementation. The assumption is that components have a function in their `.mm` file with this shape: ```objc Class<RCTComponentViewProtocol> <componentName>Cls(void) { return <ComponentViewClass>.class; } ``` I verified on GH that all the libraries out there follow this pattern. A better approach will let library owner to specify the association of `componentName, componentClass` in the `codegenConfig`. We will implement that as the next step and we will support both for some versions for backward compatibility. ## Changelog [iOS][Changed] - Change how components automatically register Differential Revision: D65614347
This pull request was exported from Phabricator. Differential Revision: D65614347 |
Summary: This change reintroduce the generation of the `RCTThirdPartyComponentProvider` but in the right place and with the right patterns. 1. We are generating it in the user space, not in the node_modules (fixes the circular dependency) 2. We are not using weak function signature that have to be implicitly linked to some symbols found during compilation The change needs to crawl the folder to retrieve the information it needs. We need to implement it this way not to be breaking with respect of the current implementation. The assumption is that components have a function in their `.mm` file with this shape: ```objc Class<RCTComponentViewProtocol> <componentName>Cls(void) { return <ComponentViewClass>.class; } ``` I verified on GH that all the libraries out there follow this pattern. A better approach will let library owner to specify the association of `componentName, componentClass` in the `codegenConfig`. We will implement that as the next step and we will support both for some versions for backward compatibility. ## Changelog [iOS][Changed] - Change how components automatically register Differential Revision: D65614347
d1e00ed
to
0e4c398
Compare
This pull request was exported from Phabricator. Differential Revision: D65614347 |
Summary: Pull Request resolved: facebook#47518 This change reintroduce the generation of the `RCTThirdPartyComponentProvider` but in the right place and with the right patterns. 1. We are generating it in the user space, not in the node_modules (fixes the circular dependency) 2. We are not using weak function signature that have to be implicitly linked to some symbols found during compilation The change needs to crawl the folder to retrieve the information it needs. We need to implement it this way not to be breaking with respect of the current implementation. The assumption is that components have a function in their `.mm` file with this shape: ```objc Class<RCTComponentViewProtocol> <componentName>Cls(void) { return <ComponentViewClass>.class; } ``` I verified on GH that all the libraries out there follow this pattern. A better approach will let library owner to specify the association of `componentName, componentClass` in the `codegenConfig`. We will implement that as the next step and we will support both for some versions for backward compatibility. ## Changelog [iOS][Changed] - Change how components automatically register Differential Revision: D65614347
0e4c398
to
bef5250
Compare
This pull request was exported from Phabricator. Differential Revision: D65614347 |
bef5250
to
569d4d2
Compare
This pull request was exported from Phabricator. Differential Revision: D65614347 |
Summary: The `RCTThirdPartyLibraryComponentProvider` has been introduced to automate the component registration of third party libraries in the apps. However, it has some serious flaws: * It is generated in the React/Fabric folder, which means that it is generated in node_modules * It is generated when the user installs the components in the app, which means that we can't prebuild and redistribute React Native as a binary * it does not work with Frameworks and dynamic linking: in this scenarion, Fabric must build in isolation and if there are third party libraries involved, the lookup of the `xxxCls` function will fail This change removes the generation of the `RCTThirdPartyLibraryComponentProvider`. In the next diffs we will implement a different mechanism to register components ## Changelog [iOS][Changed] - Stop generating the RCTThirdPartyLibraryComponentProvider Reviewed By: dmytrorykun Differential Revision: D65601939
Summary: This change reintroduce the generation of the `RCTThirdPartyComponentProvider` but in the right place and with the right patterns. 1. We are generating it in the user space, not in the node_modules (fixes the circular dependency) 2. We are not using weak function signature that have to be implicitly linked to some symbols found during compilation The change needs to crawl the folder to retrieve the information it needs. We need to implement it this way not to be breaking with respect of the current implementation. The assumption is that components have a function in their `.mm` file with this shape: ```objc Class<RCTComponentViewProtocol> <componentName>Cls(void) { return <ComponentViewClass>.class; } ``` I verified on GH that all the libraries out there follow this pattern. A better approach will let library owner to specify the association of `componentName, componentClass` in the `codegenConfig`. We will implement that as the next step and we will support both for some versions for backward compatibility. ## Changelog [iOS][Changed] - Change how components automatically register Reviewed By: dmytrorykun Differential Revision: D65614347
569d4d2
to
21479f0
Compare
This pull request was exported from Phabricator. Differential Revision: D65614347 |
This pull request has been merged in 8becc25. |
Summary:
This change reintroduce the generation of the
RCTThirdPartyComponentProvider
but in the right place and with the right patterns.The change needs to crawl the folder to retrieve the information it needs. We need to implement it this way not to be breaking with respect of the current implementation.
The assumption is that components have a function in their
.mm
file with this shape:I verified on GH that all the libraries out there follow this pattern.
A better approach will let library owner to specify the association of
componentName, componentClass
in thecodegenConfig
.We will implement that as the next step and we will support both for some versions for backward compatibility.
Changelog
[iOS][Changed] - Change how components automatically register
Differential Revision: D65614347