Summary:
To properly setup the Header Search Paths for `use_frameworks!`, we need to move the files that are in the `.../nativemodule/xxx/platform/ios` folder into the `.../nativemodule/xxx/platform/ios/ReactCommon` folder.
We have two folders to migrate: `core` and `sample`.
As a cleanup, `sample` should be extracted from the codebase and moved to RNTester or a library as it can be used as an example to add more examples in the codebase that we ship to our users.
This mimic the same folder structure we have also in `cxx` and `android`
## Changelog
[iOS][Changed] Moved the files from `.../nativemodule/xxx/platform/ios` to `.../nativemodule/xxx/platform/ios/ReactCommon`
Reviewed By: cortinico
Differential Revision: D43082851
fbshipit-source-id: 414426274d9a5ab20cc0e76cdada0c2977264b5f
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/35089
Changelog:
[General][Fixed] - Back out "Add enum example to Android/iOS rn-tester TurboModule"
This broke the rn-tester adding due to an invalid flow-enum setup. Needs further investigation
Reviewed By: cipolleschi
Differential Revision: D40714320
fbshipit-source-id: 9831276762f90df0ffaca3304382fe5925009343
Summary:
All NativeModules/TurboModules can use the following Venice-compatible API instead:
```
synthesize moduleRegistry = _moduleRegistry
```
In bridge mode, it'll look up the module via the TurboModule system/bridge.
In bridgeless mode, it'll look up the module via the TurboModule system.
Therefore, there's no need to support this API.
Changelog: [iOS][Removed] - Delete synthesize turboModuleRegistry API in RCTTurboModule
Reviewed By: fkgozali
Differential Revision: D28070740
fbshipit-source-id: d2c8285fd4c05b67fb03ce82217bf6ddfd1dd685
Summary:
We're making the getTurboModule: method required for all classes that conform to RCTTurboModule.
Many of our ObjC-only and Cxx NativeModules don't implement this method. This diff implements a getTurboModule: method on all those modules that returns nullptr.
**Question:** Why is it fine to make ObjC-only NativeModules return nullptr from their getTurboModule: method?
- Because they're only accessed from ObjC, and should appear as null on the JavaScript side. Longer term, these NativeModules will also go away.
**Question:** Why is it fine to make Cxx NativeModules return nullptr from getTurboModule: method?
- Because after D27316872, the TurboModuleManager checks if the module is a CxxModule first. If it is, we do an early return, and never call the module's getTurboModule: method.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D27316871
fbshipit-source-id: bc693f2927ab3b0de24e6e9e7699390ec0f7d729
Summary:
This new type will be valid in Flow strict mode and can be used by native modules and components to replace `Object`, with the same semantics.
This unblocks the migration of the most modules in the React Native package to Flow strict.
Changelog: [Internal] Add UnsafeObject type compatible with Flow strict mode to use in native modules and components
Reviewed By: RSNara
Differential Revision: D25540631
fbshipit-source-id: 60b80bbc84a53aecc747e3a1799cdf551e1859cd
Summary:
This is a codemod. All these NativeModules demand access to the bridge. However, they don't use it.
Changelog: [Internal]
Reviewed By: PeteTheHeat, RoelCastano
Differential Revision: D25386708
fbshipit-source-id: f05f4777d2527e96e53581e7ac58f6be47411dce
Summary:
This diff moves the code of TurboModule Core from ReactCommon/turbomodule to ReactCommon/react/nativemodule
For iOS: Pod spec name stays as "ReactCommon/turbomodule/..." for now, only the source/header location is affected. The target will be renamed/restructured closer to TurboModule rollout.
changelog: [internal] Internal
Reviewed By: RSNara
Differential Revision: D23362253
fbshipit-source-id: c2c8207578e50821c7573255d4319b9051b58a37
Riccardo CipolleschiandFacebook GitHub Bot
Christoph PurrerandFacebook GitHub Bot
Andres SuarezandFacebook GitHub Bot
Ramanpreet NaraandFacebook GitHub Bot
Rubén NorteandFacebook GitHub Bot
Kevin GozaliandFacebook GitHub Bot