Summary:
This diff formats the Java class files inside xplat/js/react-native-github. Since google-java-format was enabled in D16071401 we want to codemode the existing code so that users don't have to deal with formatter lint noise at diff-time.
```arc f --paths-cmd 'hg files -I "**/*.java"'```
drop-conflicts
Reviewed By: cpojer
Differential Revision: D16071725
fbshipit-source-id: fc6e3852e45742c109f0c5ac4065d64201c74204
Summary: Some TM lookup from native will fail assertion if done too early, because TM Manager is not initialized yet.
Reviewed By: mdvacca
Differential Revision: D15872776
fbshipit-source-id: 7616c1424816f73a45aa1d9723e7807ae10392a7
Summary:
To avoid unnecessary class loads, and better modularity, let's use string keys (enum) to access JSIModule's. For now all JSIModule's are all known inside the core infra (only FabricUIManager and TurboModuleManager right now), so let's keep it simple and explicitly list them out.
The only problem here is we lose some form of type safety...
Reviewed By: JoshuaGross
Differential Revision: D15872777
fbshipit-source-id: 9c2de7ef1e88ef3a6dff5888d644f9d8963af2a3
Summary: `ReactContext.getNativeModule` can be used to access NativeModules. With these changes, it can also be used to instantiate (if necessary) and retrieve a TurboModule.
Reviewed By: mdvacca
Differential Revision: D15167631
fbshipit-source-id: 3cb0d9a4be16cbadebbf6648c3f1481ba26513c3
Summary:
JSCallInvoker requires a `std::weak_ptr<Instance>` to create. In our C++, `CatalystInstance` is responsible for creating this `Instance` object. This `CatalystInstance` C++ initialization is separate from the `TurboModuleManager` C++ initialization. Therefore, in this diff, I made `CatalystInstance` responsible for creating the `JSCallInvoker`. It then exposes the `JSCallInvoker` using a hybrid class called `JSCallInvokerHolder`, which contains a `std::shared_ptr<JSCallInvoker>` member variable. Using `CatalystInstance.getJSCallInvokerHolder()` in TurboModuleManager.java, we get a handle to this hybrid container. Then, we pass it this hybrid object to `TurboModuleManager::initHybrid`, which retrieves the `std::shared_ptr<JSCallInvoker>` from the `JavaJSCallInvokerHandler`.
There were a few cyclic dependencies, so I had to break down the buck targets:
- `CatalystInstanceImpl.java` depends on `JSCallInvokerHolderImpl.java`, and `TurboModuleManager.java` depends on classes that are packaged with `CatalystInstanceImpl.java`. So, I had to put `JSCallInvokerHolderImpl.java` in its own buck target.
- `CatalystInstance.cpp` depends on `JavaJSCallInvokerHolder.cpp`, and `TurboModuleManager.cpp` depends on classes that are build with `CatalystInstance.cpp`. So, I had to put `JavaJSCallInvokerHolder.cpp` in its own buck target. To make things simpler, I also moved `JSCallInvoker.{cpp,h}` files into the same buck target as `JavaJSCallInvokerHolder.{cpp,h}`.
I think these steps should be enough to create the TurboModuleManager without needing a bridge:
1. Make `JSCallInvoker` an abstract base class.
2. On Android, create another derived class of `JSCallInvoker` that doesn't depend on Instance.
3. Create `JavaJSCallInvokerHolder` using an instance of this new class somewhere in C++.
4. Pass this instance of `JavaJSCallInvokerHolder` to Java and use it to create/instatiate `TurboModuleManager`.
Regarding steps 1 and 2, we can also make JSCallInvoker accept a lambda.
Reviewed By: mdvacca
Differential Revision: D15055511
fbshipit-source-id: 0ad72a86599819ec35d421dbee7e140959a26ab6
Summary: Right now JSBundleLoader is tightly coupled to CatalystInstanceImpl; this diffs adds an interface, JSBundleLoaderDelegate, that CatalystInstanceImpl implements so that we can use the bundle loader with other classes.
Reviewed By: mdvacca
Differential Revision: D13216752
fbshipit-source-id: fc406ef30f12ed9d3ed13a062dedd7b33f3b7985
Summary: Now that NativeModules are stored based on String keys instead of classnames, the old innterface to getNativeModules(Class moduleInterface) is deprecated. This interface is also incorrect since a native module with the same name may be overridden, causing issues. Getting native modules by name is also similar to what JavaScript does
Reviewed By: achen1
Differential Revision: D9697827
fbshipit-source-id: ff832bd2ea5e1c7cfe7d8c0c3a66f0d755b2c354
Summary:
This diff:
- Disables all tests but one of FabricViewTest
- Disables all tests but one of FabricBenchmarkTest
- Changes ReactAppTestActivity to run with Hermes
The reason there is only one test running in each test class, is because the tear down process of Fabric is still flaky and it produces crashes when restarting RN. We are working on this right now and we will enable the rest of the tests after that's fixed.
Reviewed By: achen1
Differential Revision: D9890700
fbshipit-source-id: a8716481eff15b77bd12b38aaaefd4e282c71f3b
Summary: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Summary:
Added systrace to the following sections
1. When Marketplace Home Fragment is created
2. On initialization of Catalyst Instance
Reviewed By: achen1
Differential Revision: D9665376
fbshipit-source-id: e48e9f50dad42c71fb2151538f65bc54939adc1e
Summary:
Adds `loadScriptFromDeltaBundle` / `jniLoadScriptFromDeltaBundle` methods to `CatalystInstanceImpl`.
These methods allow to run JS coming from a native delta client as RAM bundles, to leverage the RAM bundle mechanism for development / reload scenarios.
Reviewed By: fromcelticpark
Differential Revision: D7845140
fbshipit-source-id: b79b340f36c28939a31eb63a3c463d0792a208f7
Summary:
Includes React Native and its dependencies Fresco, Metro, and Yoga. Excludes samples/examples/docs.
find: ^(?:( *)|( *(?:[\*~#]|::))( )? *)?Copyright (?:\(c\) )?(\d{4})\b.+Facebook[\s\S]+?BSD[\s\S]+?(?:this source tree|the same directory)\.$
replace: $1$2$3Copyright (c) $4-present, Facebook, Inc.\n$2\n$1$2$3This source code is licensed under the MIT license found in the\n$1$2$3LICENSE file in the root directory of this source tree.
Reviewed By: TheSavior, yungsters
Differential Revision: D7007050
fbshipit-source-id: 37dd6bf0ffec0923bfc99c260bb330683f35553e
Summary: It's now unnecessary to declare which JS modules you want to expose on your package. To upgrade, remove all overrides of `createJSModules` and keeping calling your JS modules as before.
Reviewed By: AaaChiuuu
Differential Revision: D5229259
fbshipit-source-id: 1160826c951433722f1fe0421c1200883ba1a348
Summary:
This change is very simple, fix a wrong spelling.
Closes https://github.com/facebook/react-native/pull/14268
Differential Revision: D5153788
Pulled By: javache
fbshipit-source-id: a163e1032661f54a802b3bfcbdf802a80b88545d
Summary: Fixes a race condition where JS module functions could be called in between ##initializeWithInstance(catalystInstance);## and ##CatalystInstance#runJSBundle##, before the BatchedBridge in JS was set up. We now guarantee that all JS module methods that are called after `ReactContext#hasActiveCatalystInstance()` returns true will have the batched bridge created and ready to use.
Reviewed By: lexs
Differential Revision: D3258651
fb-gh-sync-id: 66e66533cc86d185e7c865376d6a5cdc6520d2d4
fbshipit-source-id: 66e66533cc86d185e7c865376d6a5cdc6520d2d4