Summary:
Renaming the `better` utilities to `butter`:
- to prevent claims that this library is superior to others - it really depends on use cases
- to indicate ease of use throughout the codebase, easily spread like butter
Changelog: [C++][Changed] Renaming C++ better util to butter, used by Fabric internals
Reviewed By: JoshuaGross
Differential Revision: D33242764
fbshipit-source-id: 26dc95d9597c61ce8e66708e44ed545e0fc5cff5
Summary:
The previous diff shows how `overflowInset` could improve hit test algorithm performance. This diff adds experiment to it in order to:
1. Understand the perf improvement in production
2. Provide quick way to rollback in production -- the changes are used by FB4A as well as VR
3. The changes will pass more instructions over JNI, which may have impact on perf.
To share the MC param values in both Java and C++ side, the value is hosted by `ReactFeatureFlags` and fetched in `FbReactInstanceHolder`.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33179310
fbshipit-source-id: 327100d41f7b5a668ff0d2afabcdd1fc16cb5a18
Summary:
This diff adds `overflowInset` values in RN Android. These values are used to give an enlarged boundary of a view group that also contains all its children layout. Here is [the post](https://fb.workplace.com/groups/yogalayout/permalink/2264980363573947/) that discuss more on why this is useful. I steal the pic in that post here as TLDR:
{F687030994}
In the above case, we will get overflowInset for ViewGroup A as something like `top: 0, right: -20, bottom: -20, left: 0`.
This has been added in the [Fabric core](https://fburl.com/code/f8c5tg7b) and [in IOS](https://fburl.com/code/vkh0hpt6). In Android, since we used to ignore all event coordinates outside of a ViewGroup boundary, this is not an issue. However, that caused unregistered touch area problem and got fixed in D30104853 (https://github.com/facebook/react-native/commit/e35a963bfb93bbbdd92f4dd74d14e2ad6df5e14a), which dropped the boundary check and made the hit test algorithm in [TouchTargetHelper.java](https://fburl.com/code/dj8jiz22) worse as we now need to explore all the child node under ReactRootNode.
This perf issue is getting obvious when a view loads too many items, which matches our experience with "Hover getting slow after scrolling", "Hover getting slow after going back from PDP view", and "The saved list view (in Explore) is very fast (because it has very few components)"
To fix this issue, I added the support to `overflowInset` to RN Android by
1. Sending the `overflowInset` values from Binding.cpp in RN Android as a separate mount instruction
2. Update `IntBufferBatchMountItem.java` to read the int buffer sent over JNI, and pass the `overflowInset` values to `SurfaceMountingManager.java`
3. Creating new interface `ReactOverflowViewWithInset.java` and extending the existing `ReactOverflowView.java` usages
4. Adding implementation of getter and setter for `overflowInset` in various views
5. Update `TouchTargetHelper.java` to read the values and check boundaries before exploring ViewGroup's children
Note that in #3 I didn't change `ReactOverflowView.java` interface directly. I am concerned about backward compatibility issues in case this interface is being used in OSS. I suggest we deprecate it as we are not using it anymore in our code.
Changelog:
[Internal][Android]
Reviewed By: JoshuaGross
Differential Revision: D33133977
fbshipit-source-id: 64e3e837fe7ca6e6dbdbc836ab0615182e10f28c
Summary:
Binding.cpp shares many responsibilities, including surface management and mount. This change refactors mount (and mount items) into separate files, while retaining the same functionality and interface.
Changelog:
[Internal][Android] - Refactor mount into FabricMountingManager
Reviewed By: mdvacca
Differential Revision: D32977902
fbshipit-source-id: 07cdf5a19033fccaa81901e5b9a4d44192ec7853
Summary: Changelog: [Internal] - Update the source of the changes in generated files, no longer bump-oss-version but set-rn-version
Reviewed By: sota000
Differential Revision: D33110408
fbshipit-source-id: 8cd5004f5d40dde82fe4d6271d5b8598cd27ca31
Summary:
Inits RootView to display size for the early surface start experiment.
Before that experiment, we always had the view measured before the surface was initialized, but here layout can sometimes happen before measure. Surface defaults use [0; Inf) for size constraints, potentially causing a crash in Yoga. This change avoids that by making a guess on default layout size with `displayMetrics`
Changelog: [Internal]
Reviewed By: feedthejim
Differential Revision: D33190397
fbshipit-source-id: 3b1b84135a4980ef2fde4024ec84a448199e00b8
Summary:
This diff adds extra logging to track how long does it take to exeucte different stages of the fabric commit
changelog: [internal] internal
Reviewed By: philIip
Differential Revision: D33183070
fbshipit-source-id: 69e31bef69c9d9ec57dc7e00e4c36e278eb30cb6
Summary:
Just released a new version that supports Android App Bundle correctly
https://github.com/facebook/SoLoader/releases/tag/v0.10.3
Reviewed By: passy
Differential Revision: D33167010
fbshipit-source-id: 69c54b1674b06b05a01a468d9f324475e5c232cf
Summary:
Similar to the previous diff, we should not allow view group that has clipChildren set to true to respond events that are out of bounds.
Changelog:
[Internal][Android]
Reviewed By: ShikaSD
Differential Revision: D33102331
fbshipit-source-id: de3a5ffdd5293ada1d2c211659e79edc697b5d15
Summary:
In D30104853 (https://github.com/facebook/react-native/commit/e35a963bfb93bbbdd92f4dd74d14e2ad6df5e14a), we added fix to the issue where touches on the child view that is outside of its parent view's boundary are not registered. The only exception to that is if the parent view has overflow style `overflow: hidden`. In that case, touches happen outside of the parent view should be ignored.
{F686521911}
That fix works, but it increases the complexity for the DFS algorithm used to find the touch target in two ways:
1. Before we only traverse views that contain the touch event point. If the touch event point is outside of the view, we won't step in and traverse that part of the tree. This is actually what caused the initial problem. The fix removed that boundary check (where `isTransformedTouchPointInView` used to do) and push it later. This increases the number of tree traversal a lot.
2. The check for `overflow: hidden` is happened after we find a potential target view, which means we've spent time to find the target view before we decide if the target view is even a candidate.
This diff aims to update for the #2 item above. Since we are checking the style of the parent view, not the target view, it's not necessary to check that after we find the target view. We could check the parent view and if it has `overflow: hidden` on it, any pointer event that are not in the boundary can be ignored already.
Changelog:
[Internal][Android]
Reviewed By: mdvacca, ShikaSD
Differential Revision: D33079157
fbshipit-source-id: c79c2b38b8affb9ea0fd25b5e880b22466ab7ed9
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32770
Fest is EOL and is replaced by assertj, originally a fork of Fest. This change replaces the usages in internal tests and removes the dependency.
Changelog:
[Internal][Android] Replace fest with assertj
Reviewed By: genkikondo
Differential Revision: D33143454
fbshipit-source-id: c1cbe5b064d007018f73858b2913806c11aa08af
Summary:
Scheduler and JavaUIManager mutexes share the lifetime (between install-uninstall), so we can use singular shared lock to ensure that both sections are locked exclusively for install/uninstall and in shared mode for access.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D33130686
fbshipit-source-id: bf283fd5410e386d2635645e17680a9f4cb7f288
Summary:
Adds a return value to `MessageQueueThread#runOnQueue`, it's implementors and one caller.
It is currently possible for a callback to not be called (because the HandlerThread has been shutdown). If the callback is mission-critical (frees resources, releases a lock, etc) the callee has no indication that it needs to do something.
This surfaces that information to the callee.
Changelog:
[Android][Changed] - Made `MessageQueueThread#runOnQueue` return a boolean. Made `MessageQueueThreadImpl#runOnQueue` return false when the runnable is not submitted.
Reviewed By: RSNara
Differential Revision: D33075516
fbshipit-source-id: bd214a39ae066c0e7d413f2eaaaa05bd072ead2a
Summary:
Fabric uses a cache where it stores the result of the text measurement in C++ (to avoid unnecessary text measurement that are very costly). This cache has a "max size" of 256 and this size is not enough to store all the texts we have in the screen
In my tests, the amount of texts being measured are ~290 and after scrolling many times they increase to 611.
This diff increases the size of the TextMeasure to 1024 for users in the experiment. As a result this improves performance of HoverEvents by +5x times (see test plan)
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D33112788
fbshipit-source-id: e15feecf0f54da62b252892d37a64fb4ead29e22
Summary:
With the updates to touch processing rolled out, we can remove the feature flag and clean up the old code. The old path is now used exclusively by legacy renderer and Fabric uses new `EventEmitter#receiveTouches` method to process touches.
Changelog:
[Changed][Android] - Update touch processing internals
Reviewed By: mdvacca
Differential Revision: D32953664
fbshipit-source-id: 517a4ce6ce9bc15528c2db94d7d11bdff8b78743
Summary:
Applies suggestions from clang-tidy. The automatic linter seems to be broken atm, so I used default config from Android Studio, filtering out meaningless suggestions.
Changelog: [Internal]
Reviewed By: cortinico, sammy-SC
Differential Revision: D32994138
fbshipit-source-id: e8edf53f0cb8b0eda4ff8bb8bf8f5196827efd68
Summary:
Follow up to https://github.com/facebook/react-native/issues/32683 to also link hermes-inspector statically.
## Changelog
[Android] [Fix] - Static link for hermes-inspector
Pull Request resolved: https://github.com/facebook/react-native/pull/32694
Test Plan: Tested a clean build and made sure hermes-inspector.so doesn't exist anymore.
Reviewed By: cortinico
Differential Revision: D32791208
Pulled By: ShikaSD
fbshipit-source-id: 6076b263469b9e2c6176d488d13292d4f1731dcc
Summary:
The IDE warning suggests that passing folly::dynamic by value will create a copy on each call.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D32978154
fbshipit-source-id: a47a60c332a9d299eb2110d3537dfab0bc2398b6
Summary:
Originally introduced in D2022018
Tried to make the processor optional when no rounding is required, but found even that was not strictly necessary.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D32675492
fbshipit-source-id: 8dfdbf0e4347155045f77b1fba00a59086fe7a33
Summary:
This diff add custom prediction for fling distance support. This is needed for customize fling animator to calculate predicted fling distance, instead of using the overscroller that may not be used by the animator.
More context on this -- when fling happens, our code will first predict the final fling position `p`, apply the snapping logic to decide the expected snapping position `pSnapping` given `p`, scroll velocity and children layout, then trigger the overscroller (existing) or custom fling animator to finish the fling.
Currently, the prediction logic is done with overscroller, and custom fling animator has no control over how the predicted fling distance should be. Changes in this diff allow the animator to override `getExtrapolatedDistance` method and provide that information.
Changelog:
[Android][Added] - Add new API for custom fling animator to provide predicted travel distance for its fling animation.
Reviewed By: mdvacca
Differential Revision: D32571734
fbshipit-source-id: d34b969206f8b6cb5c68d2f50a18749bfebbc97e
Summary:
This diff refactors method `predictFinalScrollPosition` in `ReactScrollView` and `ReactHorizontalScrollView` to the helper class. This will make future changes to the prediction logic easier.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D32571735
fbshipit-source-id: 7e7e21ac51f929a017cd43de094ed39478fe4032
Summary:
This diff fixes an edge case where scroll to the end of the list may trigger a bounce back effect.
This issue is a regression from D32487846 (https://github.com/facebook/react-native/commit/f70018b37532622f08f20b2c51cdbfca55d730ea) (See [this comment](https://www.internalfb.com/diff/D32487846 (https://github.com/facebook/react-native/commit/f70018b37532622f08f20b2c51cdbfca55d730ea)?dst_version_fbid=263960175698224&transaction_fbid=566201141113715)) that zero velocity fling at the end of the scroll view makes the next fling animator use previous post animation position. This is due to cached `postAnimationValue` is applied mistakenly.
- Pass velocity instead of velocity sign to the helper class
- Update helper class logic to decide if we need to use post animated value from last fling animation
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D32566010
fbshipit-source-id: 1c61659030151f8f2c7648ca901b8b4158835538
Summary:
This diff fixes an edge case where fling and snap failed to find the correct target position when children views not fill up all the scrollable space. In this case, the target position would be calculated as the end of the scrollable space, which case the snap logic to go to the end of the scrollable area, instead of stop at the expected snapping position.
Changelog:
[Android][Fixed] - Fix fling and snap with recycler viewgroup where fling to the end of scrollable distance when it goes over current rendered children views.
Reviewed By: mdvacca
Differential Revision: D32565459
fbshipit-source-id: 319ef6e2d4e1c4deb9e45ed02c1bff7d807575c3
Summary:
changelog: [internal]
Background executor has been shipped on both platforms for a long time.
I've kept the flag around because I wanted to run tests and compare Concurrent Mode vs Background Executor. The intention was to see if we can get rid of Background Executor to simplify the threading model.
Since then, React team has moved away from Concurrent Mode towards more gradual rollout of concurrent rendering and it no longer makes sense to do this comparison. Right now, we don't have a concern with concurrent rendering and Background Executor. If we ever want to run the an experiment, this gating will need to be added again.
Reviewed By: javache
Differential Revision: D32674798
fbshipit-source-id: a1e51c9c5b8e48efa4cb0f25379d58e7eb80ccd9
Summary:
I've noticed that the `performance.now()` implementations differ on iOS and Android.
iOS:
```objc
PerformanceNow iosPerformanceNowBinder = []() {
// CACurrentMediaTime() returns the current absolute time, in seconds
return CACurrentMediaTime() * 1000;
};
```
Android:
```c++
double reactAndroidNativePerformanceNowHook() {
auto time = std::chrono::steady_clock::now();
auto duration = std::chrono::duration_cast<std::chrono::nanoseconds>(
time.time_since_epoch())
.count();
constexpr double NANOSECONDS_IN_MILLISECOND = 1000000.0;
return duration / NANOSECONDS_IN_MILLISECOND;
}
```
For consistency, I thought why not just use the same implementation on both iOS and Android.
It also seems more logical to use Chrono on iOS, since it has nanosecond precision and we just multiply it to milliseconds, whereas `CACurrentMediaTime` multiplies to seconds, and we divide it down to milliseconds again.
## Changelog
(internal change only)
Pull Request resolved: https://github.com/facebook/react-native/pull/32695
Test Plan:
Run on iOS and Android:
```ts
const now = global.performance.now()
console.log(`${Platform.OS}: ${now}`)
```
Reviewed By: feedthejim
Differential Revision: D32793838
Pulled By: ShikaSD
fbshipit-source-id: e7967780be95956a75a3a3757311af0077976d23
Summary:
The helper class for ScrollView should not need to detect the scroll direction. If it has to do so, that means the corresponding logic should live in the `ReactScrollView` or `ReactHorizontalScrollView` respectively.
This diff is to remove the scroll direction detection logic from the scroll view helper. Long term we should keep it this way as the shared code got moved to the helper class from the scroll view classes.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D32514429
fbshipit-source-id: 2165f2eba90cc25d14834c39148fe8ce8805bea6
Summary:
This diff fixes two edge case (similar to a race condition) that caused unexpected behaviors.
**Problem one**
{F680816408}
The previous fling animation is not canceled when user starts to scroll or drag. This is causing both the animation and scroll are setting the scroll position. Depends on the animation path and scroll speed, there may be cases where the [velocity calculation](https://fburl.com/code/010lsu72) ends up getting reversed values. See P467905091 as an example where you can see `mXFlingVelocity` goes back and forth from positive to negative.
It's hard to see if the wrong values are in the middle, but if that happens in the end of user gesture, the velocity for the next fling would be wrong. It shows a "bounce back" effect, and can be triggered when user makes small quick joystick scrolls in one direction.
**Problem two**
{F680821494}
There is a gap between animator's `onAnimationEnd` lifecycle method [finished](https://fburl.com/code/6baq04ne) and the `Animator#isRunning` API to return false. This is causing issues for `getPostAnimationScrollX` where we [decide to return](https://fburl.com/code/hzzugvch) the animated final value or the scroll value. User may see the `-1` value got used for the next fling start value, and the whole scroll view goes back to the beginning of scroll view and starts to fling.
This happens when the previous fling animation finishes and the animated final value is set to -1, but at the same time the next fling starts before `isRunning` returns false for the previous animation.
**Solution**
The problems are fixed by
- Do not reset animated final value to -1 in `onAnimationEnd` method
- Add `mIsFinished` states and use it to track animation finish signal, instead of using `isRunning` API
- Update logic where we decide to return the correct value for the next animation starts point. We will return previous animated final value when the animation got canceled, and user is going towards that value from the current scroll value.
Changelog:
[Android][Fixed] - Fixed edge case for quick small scrolls causing unexpected scrolling behaviors.
Reviewed By: javache
Differential Revision: D32487846
fbshipit-source-id: f1b0647656e021390e3a05de5846251a4a2647ff
Summary:
Preallocation can take 10-20% of time when creating new nodes. (according to systrace measurements). At the moment, we are executing all preallocation calls in JS thread, potentially slowing down the progress there. Moving them to bg thread is a simple micro-optimization that ensures we return the node to JS as soon as possible.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D32677843
fbshipit-source-id: 3df47ae9aa365a8db720d71e2423c87659e9128c
Summary:
Removes extra .so files by merging built-in components into libfabricjni.so
These components shouldn't be referenced in outside modules, so merging them is trivial atm.
Changelog:
[Internal][Android] - Compile native components into static libraries
Reviewed By: cortinico
Differential Revision: D32677572
fbshipit-source-id: fc1a6c5a2832ee49e438c30856562f85677514ea
Summary:
Noticed we explicitly dropped the `allow_jni_merging` while not actually using it anywhere, and that we didn't have `fbandroid_allow_jni_merging` on some other libs.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D32355868
fbshipit-source-id: 6bd3fcc395e3dcacf4a8fc1033d471b2ffb0e8af
Summary:
This diff makes the fling animator cuztomizable, so that the subclasses can have their own animation for fling behavior.
Before the diff, we rely on the `OverScroller` to `fling`, which has some issues with Spline interpolation being messed up due to the clamped fling distance (See more details in T105464095). This may not be a big issue for mobile when user touches screen, but in VR environment this shows up very clearly with joystick events. To fix that properly without affecting mobile behavior, I added a new interface `HasFlingAnimator` from the helper, and implemented with default fling animator in the OSS ScrollView.
We should consider adopt a suitable animator for mobile platform, as the non-smooth fling effect is also happening in mobile.
- Add interface `HasFlingAnimator` to `ReactScrollView` and `ReactHorizontalScrollView`
- Add default fling animator
- Depend on if the default animator is used, customize the flingAndSnap behavior
Changelog:
[Internal]
Reviewed By: JoshuaGross
Differential Revision: D32382806
fbshipit-source-id: 08f03350f6a9b9fc03414b4dcb9977b9f33603ba
Summary:
We have `LOCAL_SHARED_LIBRARIES` that are getting longer and are
making reviewing them on Diffs quite hard.
Having all the list of the dependency on a single line is suboptimal
and it makes hard to find duplicated entries.
I've updated the longest `LOCAL_SHARED_LIBRARIES` to be multilines and
I've sorted the entries here.
Changelog:
[Internal] [Changed] - LOCAL_SHARED_LIBRARIES
Reviewed By: ShikaSD
Differential Revision: D32695127
fbshipit-source-id: f5b381c501ddff083ef9f4baaca6c4c8c9523368
Summary:
This Diff fixes a crash happening as the user uses AppCompat 1.4.0
as a dependency in their App and uses a `TextInput` component.
The crash happens as `mFabricViewStateManager` is accessed during
the ctor of the superclass, and is not yet initialized.
Fixes#31572
Changelog:
[Android] [Fixed] - Fix crash on ReactEditText with AppCompat 1.4.0
Reviewed By: ShikaSD
Differential Revision: D32674975
fbshipit-source-id: efa413f5e33527a29fbcfa729e8b006ecb235978
Summary:
AGP 7.x is changing the path where we can find
the precompiled static libraries. Therefore is getting complicated
to share prebuilt `.a` files. I'm updating `libruntimeexecutor` to be
a shared library instead so this will solve this issue for now.
Changelog:
[Internal] [Changed] - Update libruntimeexector to be a shared lib rather than a static lib
Reviewed By: ShikaSD
Differential Revision: D32646112
fbshipit-source-id: ce42e930076c1d3b5f54f3d8adcca1c38909d0fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/32640
This Diff shows how an application can provide a custom Fabric Components Registry.
The idea is to extend the CoreComponentsRegistry from rncore to provide the extra
components that are generated from RNTester.
Please note that this Diff can't be shipped as it is and should be rebased on top of:
- D32493605 (https://github.com/facebook/react-native/commit/aa4da248c12e3ba41ecc9f1c547b21c208d9a15f) As the CLANGFORMAT is disabled for RNTester at the moment
- D32045059 (https://github.com/facebook/react-native/commit/d29f3d2a6b84c17ad057f4e9c8dc35b3fe16fb19) and D32128979 as they're effectively adding the sample component and the iOS code.
Changelog:
[Internal][Added] - Adding a Custom Fabric Component to RNTester
Reviewed By: ShikaSD
Differential Revision: D32498360
fbshipit-source-id: 1a737359498dddb571c8a445bec18e5dbcf53e04
Summary:
This diff updates the BaseViewManager in order to store metadata in views that are handling JS events.
This information will be used later in the stack to optimize dispatching of hover events and fix viewFlattening bugs
changelog: [internal] internal
Reviewed By: philIip
Differential Revision: D32253127
fbshipit-source-id: b6b74f0b1a5b8cc652b3ac3fff42165ee4ce85e1
Summary:
This diff updates the ViewConfigs in RN Android to add support for onEnter/onExit/onMove events.
Open questions:
- Should we just remove the override for RN VR: https://www.internalfb.com/code/ovrsource/[c82b81893393ad0c6f8c6e7f347e82bba39dc8cc]/arvr/js/libraries/reactvr/VrShellPanelLib/rn-support/setUpViewConfigOverrides.js
- Should we use w3c naming now (e.g. onPointerEnter / onPointerExit / onPointerMove) ? or should we migrate to it later? what would be the effort for VR to migrate now to onPointerEnter / onPointerExit / onPointerMove?
changelog: [Android][Changed] Add ViewConfigs to support onEnter/onExit/onMove events
Reviewed By: RSNara
Differential Revision: D32253129
fbshipit-source-id: 539d8672825c7f18f0b6a2570764a5988cd936bc
Summary:
Changelog: [Internal]
# Context
Whilst looking at Marketplace Loom traces, ShikaSD made the remark that we could potentially start the JS work much earlier instead of waiting for the View.onMeasure call, a behaviour that is already built-in Venice.
Reviewed By: ShikaSD
Differential Revision: D32559505
fbshipit-source-id: cc6337955ad2b6a6581a0347f1f976679eaca54d
Summary:
This is expected with Suspense/CM enabled. We are measuring the perf impact of extra CREATE instructions atm, and will revert the change if it regresses too much.
Changelog:
[Internal]
Reviewed By: sammy-SC
Differential Revision: D32558829
fbshipit-source-id: 2e0c91be3aba4ca632814739aed6b8964e21b5a8
Summary:
This diff refactors the scroll animation from `ReactScrollView` and `ReactHorizontalScrollView` into the `ReactScrollViewHelper` to reduce repeated code. The `Animator` is now shared between all the scroll views in the app, which I believe is the right behavior.
It also helps to make the animator changes in future diffs apply to both horizontal and vertical scroll view.
- Move `reactSmoothScrollTo` to `smoothScrollTo` in the helper class
- This means one Animator for all ScrollViews
- Move `updateStateOnScroll` to the helper class
- Add interface for accessing instance scroll state properties in ScrollView
- This means each ScrollView keeps their own scrolling state
- Use `Point` class for pairs of x and y values
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D32372180
fbshipit-source-id: 529180eea788863689c3b440191ed50c5a6f04e5
Summary:
Ensures (under a flag) that CREATE instructions will be issued even if the node was supposed to be preallocated before from create or clone. This addresses cases when differ considers nodes to be deleted->created, but we skip the "create" part because of revision check.
Changelog:
[Internal] Disable node revision checks during mount under a flag
Reviewed By: sammy-SC
Differential Revision: D32440831
fbshipit-source-id: 4da8c4961fd7bc43c8f4166798bdfb5d897184e0
Summary:
I'm adding a `EmptyReactNativeConfig` for Java as we had a similar class in C++.
Ideally inside the Playbook we can allow users to use this class rather than having to
create an anonymous inner class.
Changelog:
[Internal] [Added] - Introduce EmptyReactNativeConfig inside Java
Reviewed By: ShikaSD
Differential Revision: D32277916
fbshipit-source-id: f6bbeb0477681d536dfd89930b732609add7c43a
Kevin Gozali
Xin Chen
Andrei Shikov
Luna Wei
David Vacca
Sim Sun
Marshall Mann-Wood
Janic Duplessis
Genki Kondo
zpd106
Samuel Susla
Marc Rousavy
Pieter De Baets
Nicola Corti
Paige Sun
Jimmy Lai
Liron Yahdav