Summary:
This parameter used to be useful for a custom format hermes was developing,
but since Hermes now outputs the Chrome format it isn't useful.
Chrome actually disallows prettified JSON, and requires a special version that is faster to parse.
Therefore, `compact` was the only supported mode.
Changelog: [Internal] Remove compact parameter from `createSnapshotToFile`
Reviewed By: willholen
Differential Revision: D17726742
fbshipit-source-id: 6f39af9046dff2f3b4fba822312a9a89c939ed89
Summary:
Use `reactTag` instead of address of `UIView` to map events from paper components to Fabric.
changelog: [internal]
Reviewed By: shergin
Differential Revision: D17954974
fbshipit-source-id: 0d8bf748e58f4cb6769e107bc7fd0e66b93d8f12
Summary:
This diff changes how arbitrary-node-replacing (aka `RootShadowNode::clone`) algorithm works.
Original implementation worked this way: We specified a node that needs to be replaced and a new replacement node. Then the algorithm finds a node with *the same family* as given the to-be-replaced node and replaced that with a given replacement.
The problem with this approach is that we are replacing a node that we have very little info about (we only know that it shares the same family as specified one). At the same time, we build the replacement based on the exact node that we have. Then imagine the case in which the "target" node can progress/change between a moment where we get a reference to it and a moment where we are trying to clone the tree. In this case, we will replace a "progressed" node with a modified version of the obsolete node.
Practically speaking, it was possible that during a state update we were replacing a node that just got new children with a bit older version of that with old children but with a new state.
How to deal with it? This diff introduces a new interface for this method that allows separating the target node and the actual act of cloning the corresponding node. Instead of specifying actual replacement, we now specify a function that performs the cloning/transformation on-demand on the very exact node that was in the tree at the moment of cloning.
This change does not change/affect any ownership-related relationships between trees and/or nodes.
Ideally, probably, the interface should accept ShadowNodeFamily instance instead of a ShadowNode instance to make the behavior very clear but that requires a bunch of low-level changes that it out of the scope of this fix.
```
The old approach.
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ │ │ │ │ │
│ A(r0) │ │ A(r1) │ │ A(r2) │
│ │ │ │ │ │
└─────────────────┘ └─────────────────┘ └─────────────────┘
│ │ │
│ Let's update the │ Meanwhile the node B │
▼ state of this ▼ gets new children. ▼
┌─────────────────┐ node to s1. ┌─────────────────┐ ┌─────────────────┐
│ │ │ │ │ │ Created
│ B(r0, s0) │ ───────▶ │ B(r1, s0) │ ───────▶ │ B(r2, s1) │ from
│ │ │ │ │ │ B(r0).
└─────────────────┘ └─────────────────┘ └─────────────────┘
│ │ │
┌──────┴──────┐ ┌─────────────┼─────────────┐ ┌──────┴──────┐
│ │ │ │ │ │ │ What just
▼ ▼ ▼ ▼ ▼ ▼ ▼ happe..?
┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐
│ │ │ │ │ │ │ │ │ │ │ │ │ │
│ C(r0) │ │ D(r0) │ │ C(r1) │ │ D(r1) │ │ X(r0) │ │ C(r0) │ │ D(r0) │
│ │ │ │ │ │ │ │ │ │ │ │ │ │
└───────────┘ └───────────┘ └───────────┘ └───────────┘ └───────────┘ └───────────┘ └───────────┘
The new approach.
┌─────────────────┐ ┌─────────────────┐ ┌─────────────────┐
│ │ │ │ │ │
│ A(r0) │ │ A(r1) │ │ A(r2) │
│ │ │ │ │ │
└─────────────────┘ └─────────────────┘ └─────────────────┘
│ │ │
│ Let's update the │ │
▼ state of this ▼ ▼
┌─────────────────┐ node to s1. ┌─────────────────┐ ┌─────────────────┐
│ │ │ │ │ │ Created
│ B(r0, s0) │ ───────▶ │ B(r1, s0) │ ───────▶ │ B(r2, s1) │ from
│ │ │ │ │ │ B(r1).
└─────────────────┘ └─────────────────┘ └─────────────────┘
│ │ │
┌──────┴──────┐ ┌─────────────┼─────────────┐ ┌─────────────┼─────────────┐
│ │ │ │ │ │ │ │
▼ ▼ ▼ ▼ ▼ ▼ ▼ ▼
┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐ ┌───────────┐
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │
│ C(r0) │ │ D(r0) │ │ C(r1) │ │ D(r1) │ │ X(r0) │ │ C(r1) │ │ D(r1) │ │ X(r0) │
│ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │
└───────────┘ └───────────┘ └───────────┘ └───────────┘ └───────────┘ └───────────┘ └───────────┘ └───────────┘
```
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D18229704
fbshipit-source-id: face6d0e5c240224ce49e93e783cff3172b60529
Summary:
We used to use `getTag` to check that some two nodes are clones of each other, not we have a dedicated method for that that exactly ensures that without reling on a sideeffect (wich tag equality is).
That is just much less error-prone.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D18231006
fbshipit-source-id: 6b247ed0eaded1fed8fd7fa820e80cd58602110c
Summary:
Yoga layout can be invoked on multiple threads, and gCurrentGenerationCount is a shared global without synchronization.
Changelog: [General] [Fixed] - Fix an internal thread safety issue in Yoga
Reviewed By: SidharthGuglani
Differential Revision: D18092734
fbshipit-source-id: 85753d139549b4e5507f97a56d589fb6854557fa
Summary:
This diff exposes textBreakStrategy as part of ParagraphAttributes. This is necessary to support the textBreakStrategy prop into Text for Android
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D18101404
fbshipit-source-id: e7b665cefe48cf8c764f73a1c51eede16245d1ec
Summary:
This diff extends ParagraphState to expose not only the AttributedString associated to Text components, but also ParagraphAttributes that describes the visual high level props of the Paragraph
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D18101407
fbshipit-source-id: 5f5d5ca35cc03e4bf983fd24654be9506d1901a1
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: 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
Riley Dulin
Samuel Susla
Valentin Shergin
Scott Wolchok
David Vacca
Joe Loser
Ramanpreet Nara
Andres Suarez
Joshua Gross
Janette Cheng
Peter Argany
zhongwuzw
James Ide
empyrical
Ashok Menon