Skip to content
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

Closed
wants to merge 2 commits into from

Conversation

cipolleschi
Copy link
Contributor

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:

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

@facebook-github-bot facebook-github-bot added CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. p: Facebook Partner: Facebook Partner labels Nov 8, 2024
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D65614347

cipolleschi added a commit to cipolleschi/react-native that referenced this pull request Nov 8, 2024
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
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D65614347

cipolleschi added a commit to cipolleschi/react-native that referenced this pull request Nov 8, 2024
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
cipolleschi added a commit to cipolleschi/react-native that referenced this pull request Nov 8, 2024
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
cipolleschi added a commit to cipolleschi/react-native that referenced this pull request Nov 8, 2024
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
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D65614347

cipolleschi added a commit to cipolleschi/react-native that referenced this pull request Nov 8, 2024
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
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D65614347

cipolleschi added a commit to cipolleschi/react-native that referenced this pull request Nov 12, 2024
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
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D65614347

@facebook-github-bot
Copy link
Contributor

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
@facebook-github-bot
Copy link
Contributor

This pull request was exported from Phabricator. Differential Revision: D65614347

@facebook-github-bot facebook-github-bot added the Merged This PR has been merged. label Nov 12, 2024
@facebook-github-bot
Copy link
Contributor

This pull request has been merged in 8becc25.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. fb-exported Merged This PR has been merged. p: Facebook Partner: Facebook Partner
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants