Commit Graph

8 Commits

Author SHA1 Message Date
Riccardo Cipolleschi 3a218104da Fix imports in React Bridging for Old Arch and frameworks
Summary:
In 0.71.0-RC.2, we had a regression in `use_frameworks!`.

The `use_frameworks! :linkage => :static` use to work fine with the Old Architecture.
We modified how the `React-bridging` pod is configured and, now those are broken.

This change make sure to use the right imports for React-bridging.

## Changelog
[iOS][Changed] - Fix imports in React Bridging for Old Arch and frameworks

Reviewed By: christophpurrer, cortinico

Differential Revision: D41551103

fbshipit-source-id: 4416fde92fef11eb801daf2302a57fe52732e4ef
2022-11-30 11:48:01 +00:00
Scott Kyle 6a9497dbbb Move some classes to new bridging library (#33413)
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/33413

This moves `CallbackWrapper` and `LongLivedObject` into a new "bridging" library. This library is mostly intended for use by the native module system, but can also be used separately to "bridge" native and JS interfaces through higher-level (and safer) abstractions than relying JSI alone.

Changelog:
Internal

Reviewed By: christophpurrer

Differential Revision: D34723341

fbshipit-source-id: 7ca8fa815537152f8163920513b90313540477e3
2022-03-11 12:47:51 -08:00
Arthur Kushka 009d80bf5a Dropped using namespace from TurboModuleUtils.h
Summary:
using namespace in header file is a bad practice due to many reasons as well as discouraged by `-Wheader-hygiene` compiler flag which is default for many apps

https://stackoverflow.com/questions/5849457/using-namespace-in-c-headers

Changelog:
[General][Fixed] - Fixed compilation warning due to `using namespace` being used as part of header

Reviewed By: nlutsenko

Differential Revision: D34788523

fbshipit-source-id: 2a50fbf2ac3371ff5670c600c7f5ad9055060ad2
2022-03-11 06:56:10 -08:00
Andres Suarez 8bd3edec88 Update copyright headers from Facebook to Meta
Reviewed By: aaronabramov

Differential Revision: D33367752

fbshipit-source-id: 4ce94d184485e5ee0a62cf67ad2d3ba16e285c8f
2021-12-30 15:11:21 -08:00
Ramanpreet Nara 32bfd7a857 Stop sharing LongLivedObjectCollection with the bridge
Summary:
## Context
Previously, when you'd call TurboModule methods with JavaScript callbacks, we'd [store the callbacks](https://www.internalfb.com/code/fbsource/[c503ff1b38621aebca87b2bbebeae088b01886c4]/xplat/js/react-native-github/ReactCommon/react/nativemodule/core/platform/ios/RCTTurboModule.mm?lines=173%2C248-249) into [this global LongLivedObjectCollection collection](https://www.internalfb.com/code/fbsource/[c503ff1b38621aebca87b2bbebeae088b01886c4]/xplat/js/react-native-github/ReactCommon/react/nativemodule/core/ReactCommon/TurboModuleUtils.h?lines=65). Then, when React Native's JavaScript VM got torn down, we'd [clear the global collection](https://www.internalfb.com/code/fbsource/[e26f476ce208c578f05b1edb7639d1dad5612c7d]/xplat/js/react-native-github/ReactCommon/react/nativemodule/core/ReactCommon/TurboModuleBinding.cpp?lines=49), which would ensure that we deleted all held jsi::Functions, before deleting the jsi::Runtime.

## Problem
With bridgeless mode enabled, there can be two TurboModule systems. Further, it is possible to tear down bridgeless mode, or the bridge, without tearing down the other initialization infra. In this scenario, the jsi::Function for the other initialization infra would also get deleted, which could lead to mysterious problems.

## Fix
In this diff, I refactored the jsi::Function cleanup in the TurboModule system. Now, there are 3 modes:
- kGlobalScope: Everything works as it did before
- kRCTGlobalScopeUsingRetainJSCallback: We still use the global LongLivedObjectCollection, but we do it through invoking a block passed to every ObjCTurboModule by the TurboModuleManager. This group exists to assess the impact of having each TurboModule retain/use the block. I suspect this will be negligible, but it'd be good to have actual data to back this claim.
- kRCTTurboModuleManagerScope: Every TurboModule uses a LongLivedObjectCollection that is owned by its TurboModuleManager. This should effectively fix the problem I outlined above.

Changelog: [Internal]

Reviewed By: p-sun

Differential Revision: D30019833

fbshipit-source-id: da50d884c7e37190107f570d8ed70eeda7d9ae83
2021-08-02 11:22:22 -07:00
Joshua Gross 3d1afbbda3 destroy callbacks even if they aren't called, when java object is destroyed
Summary:
JSI callbacks are only destroyed if the callback is called. If the callback is never called, we're potentially leaking a lot of callbacks.

To mitigate this, we add a wrapper object that is owned by the std::function. Whenever the std::function is destroyed, the wrapper is destroyed and it deallocates the callback as well.

Changelog: [Internal]

Reviewed By: RSNara

Differential Revision: D27436402

fbshipit-source-id: d153640d5d7988c7fadaf2cb332ec00dadd0689a
2021-04-01 16:28:26 -07:00
Vladimir Morozov 8aea93022b Remove dependency on Folly in TurboModuleUtils.h (#30672)
Summary:
The TurboModuleUtils.h includes "folly/Optional.h" which is not used and creates an unnecessary dependency on Folly.
In this PR we remove this unnecessary include.

It is required for the https://github.com/microsoft/react-native-windows/pull/6804 where we add an experimental support for the C++ TurboModules. While the C++ TurboModules use the same JSI and TurboModule code defined in react-native, we provide a layer that let them to work over the ABI-safe Microsoft.ReactNative.dll boundary. The RNW Nuget distribution with DLL files includes a few source files to create native/turbo modules that work through the ABI-safe API. The TurboModuleUtils.h is one of such files. By removing the dependency on Folly we reduce requirements for the native module code. After this PR is merged we will remove the fork of the TurboModuleUtils.h  added in https://github.com/microsoft/react-native-windows/pull/6804.

## Changelog

[Internal] [Fixed] - Remove dependency on Folly in TurboModuleUtils.h

Pull Request resolved: https://github.com/facebook/react-native/pull/30672

Test Plan:
The change does not bring any functional changes. It may only affect code compilation where some code may depend on TurboModuleUtils.h when it needs the "folly/Optional.h". The fix is add the `#include <folly/Optional.h>` there explicitly.

I had run the iOS tests and they passed:
```
yarn
pod install in packages\rn-tester
./scripts/objc-test.sh test
```

Reviewed By: mdvacca

Differential Revision: D25758927

Pulled By: fkgozali

fbshipit-source-id: 347d8f6bc333a3df67095ea0dc7221c818432fab
2021-01-04 12:04:58 -08:00
Kevin Gozali 5be44456f2 TurboModule Android: compile TurboModule C++ Core into ReactAndroid
Summary:
This is to prepare for enabling TurboModule on Android. This commit compiles in all the core files (C++) into the ReactAndroid NDK build step. This doesn't yet enable TurboModule by default, just compiling in the infra, just like for iOS.

New shared libs:
* libreact_nativemodule_core.so: The TurboModule Android core
* libreact_nativemodule_manager.so: The TurboModule manager/delegate

To be compatible with `<ReactCommon/` .h include prefix, the files had to move to local `ReactCommon` subdirs.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D23805717

fbshipit-source-id: b41c392a592dd095ae003f7b2a689f4add2c37a9
2020-09-20 14:23:43 -07:00