Introduce again com/facebook/react/turbomodule/core/interfaces/TurboModule.kt #41412
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
facebook-github-bot
added
CLA Signed
|
This pull request was exported from Phabricator. Differential Revision: D51168413 |
Base commit: f53bd56 |
mdvacca
added a commit
to mdvacca/react-native
that referenced
this pull request
Nov 10, 2023
…odule.kt (facebook#41412) Summary: The PR facebook#39682 moved all TurboModule classes into the folder com/facebook/react/internal/turbomodule/core/interfaces/TurboModule. The reasoning is TurboModule classes are internal implementation of RN and they shouldn't be part of the public API. Later we realized that com.facebook.react.internal.turbomodule.core.interfaces.TurboModule interface is actually being used by OSS developers too implement the TurboReactPackage.getReactModuleInfoProvider() method: https://reactnative.dev/docs/next/the-new-architecture/pillars-turbomodules#updating-the-calculatorpackagejava In this diff I'm re-introducing the com.facebook.react.turbomodule.core.interfaces.TurboModule interface jus for backward compatibility. Since the plan is to delete the TurboReactPackage.getReactModuleInfoProvider method in the next few months, the plan is: - Iterate on the experiments to remove TurboReactPackage.getReactModuleInfoProvider method - Once TurboReactPackage.getReactModuleInfoProvider method is ready to be deleted, there's no need to expose TurboModule interface anymore, so we will delete 'com.facebook.react.turbomodule.core.interfaces.TurboModule' and 'TurboReactPackage.getReactModuleInfoProvider' method - com.facebook.react.internal.turbomodule.core.interfaces.TurboModule will still remain in the codebase, but this will be an internal API changelog: [Android][Changed] Fix backward compatibility breakage Reviewed By: fkgozali Differential Revision: D51168413
mdvacca
force-pushed
the
export-D51168413
branch
from
3abd88b
to
3a3f6f4
Compare
|
This pull request was exported from Phabricator. Differential Revision: D51168413 |
mdvacca
added a commit
to mdvacca/react-native
that referenced
this pull request
Nov 10, 2023
…odule.kt (facebook#41412) Summary: The PR facebook#39682 moved all TurboModule classes into the folder com/facebook/react/internal/turbomodule/core/interfaces/TurboModule. The reasoning is TurboModule classes are internal implementation of RN and they shouldn't be part of the public API. Later we realized that com.facebook.react.internal.turbomodule.core.interfaces.TurboModule interface is actually being used by OSS developers too implement the TurboReactPackage.getReactModuleInfoProvider() method: https://reactnative.dev/docs/next/the-new-architecture/pillars-turbomodules#updating-the-calculatorpackagejava In this diff I'm re-introducing the com.facebook.react.turbomodule.core.interfaces.TurboModule interface jus for backward compatibility. Since the plan is to delete the TurboReactPackage.getReactModuleInfoProvider method in the next few months, the plan is: - Iterate on the experiments to remove TurboReactPackage.getReactModuleInfoProvider method - Once TurboReactPackage.getReactModuleInfoProvider method is ready to be deleted, there's no need to expose TurboModule interface anymore, so we will delete 'com.facebook.react.turbomodule.core.interfaces.TurboModule' and 'TurboReactPackage.getReactModuleInfoProvider' method - com.facebook.react.internal.turbomodule.core.interfaces.TurboModule will still remain in the codebase, but this will be an internal API changelog: [Android][Changed] Fix backward compatibility breakage Reviewed By: fkgozali Differential Revision: D51168413
mdvacca
force-pushed
the
export-D51168413
branch
from
3a3f6f4
to
8b69935
Compare
|
This pull request was exported from Phabricator. Differential Revision: D51168413 |
mdvacca
added a commit
to mdvacca/react-native
that referenced
this pull request
Nov 10, 2023
…odule.kt (facebook#41412) Summary: The PR facebook#39682 moved all TurboModule classes into the folder com/facebook/react/internal/turbomodule/core/interfaces/TurboModule. The reasoning is TurboModule classes are internal implementation of RN and they shouldn't be part of the public API. Later we realized that com.facebook.react.internal.turbomodule.core.interfaces.TurboModule interface is actually being used by OSS developers too implement the TurboReactPackage.getReactModuleInfoProvider() method: https://reactnative.dev/docs/next/the-new-architecture/pillars-turbomodules#updating-the-calculatorpackagejava In this diff I'm re-introducing the com.facebook.react.turbomodule.core.interfaces.TurboModule interface jus for backward compatibility. Since the plan is to delete the TurboReactPackage.getReactModuleInfoProvider method in the next few months, the plan is: - Iterate on the experiments to remove TurboReactPackage.getReactModuleInfoProvider method - Once TurboReactPackage.getReactModuleInfoProvider method is ready to be deleted, there's no need to expose TurboModule interface anymore, so we will delete 'com.facebook.react.turbomodule.core.interfaces.TurboModule' and 'TurboReactPackage.getReactModuleInfoProvider' method - com.facebook.react.internal.turbomodule.core.interfaces.TurboModule will still remain in the codebase, but this will be an internal API changelog: [Android][Changed] Fix backward compatibility breakage Reviewed By: fkgozali Differential Revision: D51168413
mdvacca
force-pushed
the
export-D51168413
branch
from
8b69935
to
3574f94
Compare
|
This pull request was exported from Phabricator. Differential Revision: D51168413 |
…odule.kt (facebook#41412) Summary: The PR facebook#39682 moved all TurboModule classes into the folder com/facebook/react/internal/turbomodule/core/interfaces/TurboModule. The reasoning is TurboModule classes are internal implementation of RN and they shouldn't be part of the public API. Later we realized that com.facebook.react.internal.turbomodule.core.interfaces.TurboModule interface is actually being used by OSS developers too implement the TurboReactPackage.getReactModuleInfoProvider() method: https://reactnative.dev/docs/next/the-new-architecture/pillars-turbomodules#updating-the-calculatorpackagejava In this diff I'm re-introducing the com.facebook.react.turbomodule.core.interfaces.TurboModule interface jus for backward compatibility. Since the plan is to delete the TurboReactPackage.getReactModuleInfoProvider method in the next few months, the plan is: - Iterate on the experiments to remove TurboReactPackage.getReactModuleInfoProvider method - Once TurboReactPackage.getReactModuleInfoProvider method is ready to be deleted, there's no need to expose TurboModule interface anymore, so we will delete 'com.facebook.react.turbomodule.core.interfaces.TurboModule' and 'TurboReactPackage.getReactModuleInfoProvider' method - com.facebook.react.internal.turbomodule.core.interfaces.TurboModule will still remain in the codebase, but this will be an internal API changelog: [Android][Changed] Fix backward compatibility breakage Reviewed By: fkgozali Differential Revision: D51168413
|
This pull request was exported from Phabricator. Differential Revision: D51168413 |
mdvacca
force-pushed
the
export-D51168413
branch
from
3574f94
to
79c9b10
Compare
|
This pull request was successfully merged by @mdvacca in 1891d9e. When will my fix make it into a release? | Upcoming Releases |
Othinn
pushed a commit
to Othinn/react-native
that referenced
this pull request
Jan 9, 2024
…odule.kt (facebook#41412) Summary: Pull Request resolved: facebook#41412 The PR facebook#39682 moved all TurboModule classes into the folder com/facebook/react/internal/turbomodule/core/interfaces/TurboModule. The reasoning is TurboModule classes are internal implementation of RN and they shouldn't be part of the public API. Later we realized that com.facebook.react.internal.turbomodule.core.interfaces.TurboModule interface is actually being used by OSS developers too implement the TurboReactPackage.getReactModuleInfoProvider() method: https://reactnative.dev/docs/next/the-new-architecture/pillars-turbomodules#updating-the-calculatorpackagejava In this diff I'm re-introducing the com.facebook.react.turbomodule.core.interfaces.TurboModule interface jus for backward compatibility. Since the plan is to delete the TurboReactPackage.getReactModuleInfoProvider method in the next few months, the plan is: - Iterate on the experiments to remove TurboReactPackage.getReactModuleInfoProvider method - Once TurboReactPackage.getReactModuleInfoProvider method is ready to be deleted, there's no need to expose TurboModule interface anymore, so we will delete 'com.facebook.react.turbomodule.core.interfaces.TurboModule' and 'TurboReactPackage.getReactModuleInfoProvider' method - com.facebook.react.internal.turbomodule.core.interfaces.TurboModule will still remain in the codebase, but this will be an internal API changelog: [Android][Changed] Fix backward compatibility breakage Reviewed By: fkgozali Differential Revision: D51168413 fbshipit-source-id: 921475f4beee7c6f04912558204a1911cd74b5ca
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary:
The PR #39682
moved all TurboModule classes into the folder com/facebook/react/internal/turbomodule/core/interfaces/TurboModule. The reasoning is TurboModule classes are internal implementation of RN and they shouldn't be part of the public API.
Later we realized that com.facebook.react.internal.turbomodule.core.interfaces.TurboModule interface is actually being used by OSS developers too implement the TurboReactPackage.getReactModuleInfoProvider() method:
https://reactnative.dev/docs/next/the-new-architecture/pillars-turbomodules#updating-the-calculatorpackagejava
In this diff I'm re-introducing the com.facebook.react.turbomodule.core.interfaces.TurboModule interface jus for backward compatibility.
Since the plan is to delete the TurboReactPackage.getReactModuleInfoProvider method in the next few months, the plan is:
Iterate on the experiments to remove TurboReactPackage.getReactModuleInfoProvider method
Once TurboReactPackage.getReactModuleInfoProvider method is ready to be deleted, there's no need to expose TurboModule interface anymore, so we will delete 'com.facebook.react.turbomodule.core.interfaces.TurboModule' and 'TurboReactPackage.getReactModuleInfoProvider' method
com.facebook.react.internal.turbomodule.core.interfaces.TurboModule will still remain in the codebase, but this will be an internal API
changelog: [Android][Changed] Fix backward compatibility breakage
Reviewed By: fkgozali
Differential Revision: D51168413