Summary:
The new method allows updating a ContextContainer using another one.
We will need that in the coming diffs.
Changelog: [Internal] Introducing `ContextContainer::update`
Reviewed By: sammy-SC
Differential Revision: D17960238
fbshipit-source-id: 187dcecbeee8c3de082575e53d5430d91b5338c5
Summary:
There is a mixed usage of `folly::make_unique` and `std::make_unique`. Soon, `folly::make_unique` may be removed (see [this PR](https://github.com/facebook/folly/pull/1150)). Since `react-native` only supports C++14-compilers and later, switch to always using `std::make_unique`.
## Changelog
[Internal] [Removed] - Replace folly::make_unique with std::make_unique
Pull Request resolved: https://github.com/facebook/react-native/pull/26730
Test Plan:
Running the existing test suite. No change in behavior is expected.
Joshua Gross: buck install -r fb4a, make sure MP Home and forced teardown works okay on android
Reviewed By: shergin
Differential Revision: D18062400
Pulled By: JoshuaGross
fbshipit-source-id: 978ca794c7e972db872a8dcc57c31bdec7451481
Summary:
`StateTarget` no longer uses `shared_from_this`, this allows us to remove need for `enable_shared_from_this`
I decided to put `state->commit` call inside `ShadowTree.cpp` because I needed to have access to `shared_ptr` of shadow node from outside of the class itself.
`state->commit` was originally designed to be only called by `ShadowNode` but this does not seem to be the case anymore since it is called from `UIManager` as well.
changelog: [internal]
Reviewed By: shergin
Differential Revision: D18032532
fbshipit-source-id: 75c874fd04f86adc07bfddbef3a0384e17c2067b
Summary:
In D16805827, I moved `RCTImageLoader`, `RCTImageStoreManager`, and `RCTImageEditingManager` to `CoreModules`. This was necessary to turn `RCTImageLoader` into a TurboModule. However, after D17671288 landed, it's no longer necessary to have OSS NativeModules in `CoreModules`. Therefore, I'm moving these NativeModules back to `RCTImage`.
Changelog: [iOS][Fixed] Move RCTImage NativeModules back to RCTImage
Reviewed By: shergin
Differential Revision: D17921612
fbshipit-source-id: 8ae36d2dc8deaf704313cbe2479bfa011ebcbfbc
Summary:
This change in the method signature allows removing usage of `shared_from_this()`.
After this change we will have only one usage of `shared_from_this()`.
Changelog: [Internal] Small Fabric-specific optimization.
Reviewed By: sammy-SC
Differential Revision: D17973956
fbshipit-source-id: 19818b0855565d872005062ba2992718ca89b372
Summary:
This is another step on the journey of removing `enable_shared_from_this`.
It's unclear why we used that before but it's clear now that using shared_ptr here is not necessary because all computation around happens inside the single callstack, so by definition we don't have object life-time concerns here.
Changelog: [Internal] Small Fabric-specific optimization.
Reviewed By: sammy-SC
Differential Revision: D17973957
fbshipit-source-id: 09a65c78e22083ed21b041240307f4858379cc60
Summary:
This is the first diff in the journey of removing `enable_shared_from_this` from `ShadowNode` class.
In general, using `enable_shared_from_this` is fine, it's a normal standard feature and there is nothing wrong with that... besides the fact that using this thing is usually an indication of overall poor design.
In Fabric, we don't really have a good reason for that, I think in all cases it can be avoided, so I think we should remove that.
Removing that is also code-size and perf win.
This particular diff changes the signature of `RootShadowNode::clone()` which allows removing the necessity of usage `.shared_from_this()` from callsites.
The rest changes are purely cosmetical.
Changelog: [Internal] Small Fabric-specific optimization.
Reviewed By: sammy-SC
Differential Revision: D17973958
fbshipit-source-id: 5539ceff9d11b4281a6ebe8d80e90d6bd90e44d8
Summary:
There isn't a need for using `std::shared_ptr<const void>` as the type is known.
changelog: [internal]
Reviewed By: shergin
Differential Revision: D18032518
fbshipit-source-id: 7860f9be8ba1a05a725e8bf7260a496d51194f2f
Summary:
ComponentDescriptorProviderRegistry is a new API for component registration.
Changelog: [Internal] Fabric-specific change in UIManager test.
Reviewed By: mdvacca
Differential Revision: D18010489
fbshipit-source-id: d615bfb5c9437da7358c0bd8465ab4b6525089e6
Summary:
This is the first step to migrate the registration of Android-specific `ComponentDescriptors` to `ComponentDescriptorProviderRegistry`.
`ComponentDescriptorProviderRegistry` is a never API for component registration that supports reactive registration and simplified signatures for `registry` (`add`) method.
It's tedious to keep those signatures in sync with the base class (`ComponentDescriptor`), we have an idea how to make it better by using a single struct with all params but a migration to that will be a separate effort.
The changes are pure syntactical.
Changelog: [Internal] Internal changes in Fabric.
Reviewed By: mdvacca
Differential Revision: D18010488
fbshipit-source-id: 4cbfdbcae235b32a94b38df2095c956299764e59
Summary:
`ConcreteComponentDescriptor` is a major place where dynamic dispatch calls end up. We see some amount of crashes that can be caused by an invalid pointer to a ComponentDescriptor, those checks can help verify this theory. Anyway, it's a good practice to fail earlier.
Changelog: [Internal] - Stability improvements (Fabric)
Reviewed By: sammy-SC
Differential Revision: D17991515
fbshipit-source-id: 1cac372a12b49430a3d1db66c8fc673e6adc32e9
Summary:
This diff ensures that a redbox is reported when a component is not registered in Fabric.
Changelog:
Ensure a redbox is reported when components are not registered in Fabric.
Reviewed By: shergin
Differential Revision: D17970793
fbshipit-source-id: 7afd7e6b0b9c0ff6d2bd475dbf6979d83fec093c
Summary:
We use this piece of data only for debug purposes, so there is no need to pay for that in prod.
Changelog: [Internal] - Small optimization in `ShadowNode` (Fabric)
Reviewed By: JoshuaGross
Differential Revision: D17961209
fbshipit-source-id: 2a0d609ac4d3c4815b26789551a4c51bcf91dea4
Summary:
See comments for additional commentary. On Android we pass State to all views upon creation; currently we do Preallocation of views, which means that Views are created on the mounting layer before they're technically committed. Previously we were only assocation State -> ShadowNode upon tree commit.
This meant that during Preallocation, State was accessible but the `updateState` mechanism did not work because that requires a pointer from the State back to its owning ShadowNode.
We explicitly make that connection now when creating the ShadowNode and State. This should fix or prevent many subtle bugs with State, on Android but potentially other platforms as well, since now we guarantee that State is always updateable.
Changelog:
[[Internal]]
Reviewed By: shergin, mdvacca
Differential Revision: D17937687
fbshipit-source-id: a0cfdddbf1d97f1a64624bca6aa9536620f21ad4
Summary:
`xplat` targets add different deps based on what platform the target is being built for.
for anything using `fb_xplat`, we can put all ios supermodules in `fbobjc_labels` and all android sms in `fbandroid_labels`
There's some weirdness with python targets like `thrift_gen` in `/xplat/mobileconfig/tools/generator/gen-py/BUCK` that don't have platform-specific labels because the except_for list for `fbandroid` doesn't need the `fbsource//` prefix (see changes in `/ios/isolation/infra.mobileconfig.sm`)
Changelog: [Internal]
Reviewed By: shergin, joshleibsly
Differential Revision: D17884952
fbshipit-source-id: e245364cf515b75682990094d24f789d53b1f3f5
Summary: Hiding casting madness and complexity behind a helper function to avoid bugs and improve maintainability.
Reviewed By: sammy-SC
Differential Revision: D17923549
fbshipit-source-id: 105891d85b0412fa4a17d7ae8a9e156fc1b151fb
Summary:
Destruction of Scheduler (and ShadowTreeRegistry as part of it) which has some running Surfaces is not a good thing and practically a bug on the application layer.
With this assert we throw early to flag the issue.
Changelog: [Internal] - Dev only assert indicating a broken invariant in ShadowTreeRegistry
Reviewed By: sammy-SC
Differential Revision: D17924491
fbshipit-source-id: 6b7433fe47630e993e7d5b969f3113f96124b6c9
Summary:
The Android makefiles had hard-coded paths to hermes-engine, sometimes looking in `node_modules` and other times looking in `..`. This commit implements the Node module resolution algorithm (see common.mk), which handles both of these cases and also looks further up the root if necessary, handling the case when the `hermes-engine` npm package is hoisted.
This commit does three things:
- Defines `find-node-module` and uses it in the makefiles to find `hermes-engine`
- Removes the unused `/path/to/hermes-engine/include` paths since this directory does not exist and should be `/path/to/hermes-engine/android/include` (`android`)
- Moves the definition of `REACT_NATIVE` in the makefiles to the top. It was defined after every `$(CLEAR_VARS)` invocation but was not actually cleared anyway. `$(CLEAR_VARS)` resets only `LOCAL_*` variables in this list: https://android.googlesource.com/platform/build/+/7dc45a8/core/clear_vars.mk
## Changelog
[Internal] [Changed] - Android Makefiles look for hermes-engine using Node's module resolution algorithm
Pull Request resolved: https://github.com/facebook/react-native/pull/26820
Test Plan: Run `./gradlew :ReactAndroid:installArchives`, which requires the hermes-engine paths to be correct in order to find the headers.
Differential Revision: D17923671
Pulled By: cpojer
fbshipit-source-id: 9238b8718a94080db1abbba6375a6a1d484c871d
Summary:
**Context**
For method calls from JS to Objective C, we have to convert JS values to ObjC objects/primitives. Before we can call our ObjC methods, we need to run both the ObjC primitives and objects through `RCTConvert`. This is necessary, because we sometimes convert `NSDictionary`s to special Objective C objects. Apparently, in `RCTTiming`, we also do the same with `double` (i.e: we convert a `double` arg to another `double` type with different meaning).
**Problem**
`RCTTiming` used `RCTConvert` to convert `double`s into `NSTimeInterval` (also a double). The conversion is defined like this:
```
// i.e: division by 1000
RCT_CUSTOM_CONVERTER(NSTimeInterval, NSTimeInterval, [self double:json] / 1000.0)
```
This diff implements the support necessary to make this work. For completeness, I also implemented the same functionality for `BOOL`s.
Changelog: [iOS][Fixed] Improve method argument RCTConvert logic
Reviewed By: mdvacca
Differential Revision: D17887915
fbshipit-source-id: 3246fdbf4db7e96911f16460d92448b1f1e99444
Summary:
In the legacy system, when NativeModules are supposed to be initialized on the main queue, we do the following synchronously on the main thread:
1. Done: Attach bridge on main queue
2. Register the NativeModule for frame updates on main queue
3. Post Notification that NativeModule was created on main queue
4. Attach methodQueue on main queue
5. Call new on main queue
`[RCTModuleData instance]` is the entrypoint for all of this logic.
We probably shouldn't synchronously execute all this initialization on the main queue, because it can lead to deadlocks down the road. Therefore, this diff makes it so that we still call `new` on the same thread. However, we do all other initialization in the main thread, if that's required.
Changelog: [iOS][Fixed] TurboModule initialization on the main queue
Reviewed By: PeteTheHeat
Differential Revision: D17867583
fbshipit-source-id: a88412ee1e3d93a4f9b5ab0b4dd8fc5213fa91f8
Summary:
This pull request replaces the last remaining Unix headers in `JSBigString` with their equivalent Folly Portability headers, and replaces the calls to `getpagesize()` with `sysconf(_SC_PAGESIZE)` since Folly Portability is missing that function.
The work to get this building on windows was mostly done by acoates-ms, this pull request just adds the finishing touches.
## Changelog:
[General] [Fixed] - Fixed `JSBigString` not compiling on Windows due to Unix-specific headers
Pull Request resolved: https://github.com/facebook/react-native/pull/26826
Test Plan: Compiled with Clang and with MSVC (2017)
Differential Revision: D17903214
Pulled By: cpojer
fbshipit-source-id: 230f8fb410fa81d8f13d8b6ccf1147cfc70358bf
Summary:
In a previous diff I converted this line from a shared_ptr to a raw pointer. I'm documenting the reason why in code here to proactively document assumptions.
Changelog:
[[Internal]]
Reviewed By: shergin
Differential Revision: D17884942
fbshipit-source-id: 25e29a5e3ff0695d081c8d46c1ceaa6458248e26
Summary:
Ensure that on Android, only Scheduler and UIManagerBinder directly retain UIManager. These existing JSI function-retained lambdas will not have owning share_ptr refs to UIManager, just raw pointers.
By the time the VM deallocates all JSI objects and UIManagerBinding goes away, it should be able to deallocate UIManager synchronously when UIManagerBinding is deallocated. The VM should not be executing any of these JSI functions at that time, so this should ensure that the raw pointer access is safe.
This should also provide some extremely small perf wins, and make our memory model easier to reason about, since we're using shared_ptr less often and now `UIManager` is only owned in two places: Scheduler and UIManagerBinding.
So, there are now only two places where UIManager can be deallocated:
1) Hermes is deallocated first, and UIManagerBinding is deallocated before Scheduler. Scheduler holds onto UIManager. Scheduler later is deallocated and frees UIManager; this would cause a crash if it's not completed before Hermes is torn down, but we currently ensure that Scheduler is torn down before Hermes. This is fine but we should document this contract, or make Scheduler not own UIManager.
2) Scheduler is deallocated first, decrementing the shared_ptr to UIManager. Later Hermes is torn down, which deallocates UIManagerBinding via the JSI pointer table, which synchronously deallocates UIManager before Hermes has shut down. This is the desired outcome.
Changelog:
[[Internal]]
Reviewed By: shergin
Differential Revision: D17872586
fbshipit-source-id: cbb25b5cd025f5f8597dc7a66073fe64edc57aa8
Summary:
We change yoga pod name to Yoga in 82a8080f07, so let's change it in Fabric pod.
## Changelog
[iOS] [Fixed] - Change Fabric podspec dependency yoga to Yoga
Pull Request resolved: https://github.com/facebook/react-native/pull/26800
Test Plan: Null.
Reviewed By: sammy-SC
Differential Revision: D17853707
Pulled By: mdvacca
fbshipit-source-id: 84a537f3ede7f2a86a08d532ffbbe4bf23cbf846
Summary: Storing a Bridge introducing an retain cycle, so we need to store that weakly.
Reviewed By: sammy-SC
Differential Revision: D17773698
fbshipit-source-id: 824a83a6086f9ae6efb7c458d833931954c55643
Summary: We need to have a weak semantic for the ManagedObjectWrapper, this diff implements that.
Reviewed By: sammy-SC
Differential Revision: D17773699
fbshipit-source-id: 978fa62191361c3b2c0e46c423240831ed1dd233
Summary: In D16805827, I moved `RCTImageLoader`, `RCTImageStoreManager`, and `RCTImageEditingManager` to `CoreModules`. This was necessary to turn `RCTImageLoader` into a TurboModule. However, after D17671288 landed, it's no longer necessary to have OSS NativeModules in `CoreModules`. Therefore, I'm moving these NativeModules back to `RCTImage`.
Reviewed By: PeteTheHeat
Differential Revision: D17720575
fbshipit-source-id: 44b07cfa07cbb2b87254132810f86974edc7edab
Summary:
`MountingCoordinator::waitForTransaction()` allows waiting for a new coming transaction synchronously, as efficient as waiting for a mutex.
This feature can be used to implement more high-level synchronous rendering APIs.
Reviewed By: mdvacca
Differential Revision: D17629425
fbshipit-source-id: acd91b941e4d6d43bc4518f332a1604e14506be9
Summary: We need commands to work with `LegacyViewManagerInterop`. We will need to rethink this once Fabric has command-execution pipeline in place.
Reviewed By: shergin
Differential Revision: D17787294
fbshipit-source-id: a6b3dbfae41f04e7e7f5bafb1f7b4ad0de0eedc3
Summary:
LegacyViewManagerInterop layer can now handle events as well.
We expose `eventInterceptor` from `NSComponentData`, that way we can hook into event dispatching that happens within `NSComponentData`.
Coordinator has a map of `UIView -> reactTag` which it uses to figure out to which component view to forward the event.
New `LegacyViewManagerInteropViewEventEmitter` exposes APIs to send `folly::dynamic` to javascript.
Reviewed By: shergin
Differential Revision: D17765834
fbshipit-source-id: 25e75e445b32c69ec9ab0189c4ab7fba5f8c7b5d
Summary:
ComponentDescriptor owns a coordinator which is initialised with ViewManager that it represents.
Coordinator is passed to ComponentView through state and ComponentView asks the coordinator for view.
Later, ComponentView will ask coordinator to configure view with specified props.
Reviewed By: shergin
Differential Revision: D17670444
fbshipit-source-id: e920c5c4f033884c4b539ce711286f71c887d896
Summary:
# LegacyViewManagerInterop is born
LegacyViewManagerInterop is a component that should make it possible for legacy components to work in Fabric, new renderer.
This is just a first stage that prints keys of props to screen together with component name.
Reviewed By: shergin
Differential Revision: D17552827
fbshipit-source-id: c3e062f413727729e6a9b683c60f59f0292cc63b
Summary:
We use `ViewManager.onMeasure` to perform measurements of Android views and pass the measured size back to Yoga. For Android in order to the report correct dimensions of a View, this View must be created using a Context that has a theme associated with it. Before, `onMeasure` only had ReactApplicationContext passed as the first parameter and ReactSwitch, for example, could not be measured correctly (because it uses the size of the thumb drawable, which is extracted from the current theme). This diff adds surfaceId as the first parameter of `FabricUIManager.measure`, so that we can retrieve ThemedReactContext and pass it to `ViewManager.onMeasure`.
The size of the Switch component is still incorrect, but at least the size reported back to Yoga is the same as in Paper. So there is more investigation necessary why this happens in Fabric. I will investigate and publish another diff with the fix.
Reviewed By: JoshuaGross, shergin
Differential Revision: D17625959
fbshipit-source-id: 48197a61240fb13042bef3e9f5d681acacc702fb
Summary:
In this diff we integrate the Switch component on Android in Fabric. Since the component has a custom measure function, we need to write some C++ to call the measure method in Java.
The component isn't fully functional yet (setNativeProps isn't supported in Fabric) and has some problems with measuring itself. I will fix the component in the next diffs in this stack.
Reviewed By: JoshuaGross
Differential Revision: D17571258
fbshipit-source-id: be4e201495b9b197ddec44ee3484357bfb6225a8
Summary: I was trying to debug an issue with a method signature mismatch last week, but was having trouble figuring out the problem because the error I was getting was unrelated - apparently JNI will sometimes swallow the error and just fail mysteriously later on. Ramanpreet showed me this macro that will throw any pending exceptions, so let's do that after we try to lookup the Java method in case it fails.
Reviewed By: RSNara
Differential Revision: D17680121
fbshipit-source-id: 1f23e49014f7cc1616e111386d440637e6a74677
Valentin Shergin
Joe Loser
Samuel Susla
Ramanpreet Nara
Andres Suarez
David Vacca
Joshua Gross
Janette Cheng
Peter Argany
zhongwuzw
James Ide
empyrical
Ashok Menon
masaaki1915
Adam Ernst
Oleksandr Melnykov
Emily Janzer