Summary: This diff migrates `SwipeRefreshLayoutManager` to use the generated `AndroidSwipeRefreshLayoutManagerDelegate`.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D17225894
fbshipit-source-id: e659d2a9cb5dba42c589559f61a0e98330e21612
Summary: This diff migrates `ReactModalHostManager` to use the generated `ModalHostViewManagerDelegate` for setting its properties.
Reviewed By: mdvacca
Differential Revision: D17205817
fbshipit-source-id: 6724302fd4301f9df92df04fcfb41f0c2c939d9f
Summary: This diff migrates `ReactSliderManager` to use the generated `SliderManagerDelegate` for setting its properties.
Reviewed By: mdvacca
Differential Revision: D17203078
fbshipit-source-id: 726736ef275074ecb799b334342ac64976153e2b
Summary: Small adjustment to order of operations. In case eventEmitter is nil, we still want to set image to nil.
Reviewed By: shergin
Differential Revision: D17503570
fbshipit-source-id: fd013c60e1188bcf63ff28ff7aad814582a3ae34
Summary: The OSS change in this diff allows `RCTDisplayLink` to call out to an observer, even if the `RCTModuleData` isn't well formed. This is the case in bridgeless RN.
Reviewed By: ejanzer
Differential Revision: D17438647
fbshipit-source-id: 00d4d61d9126902180a7a77fc702f4221cf4d779
Summary: The OSS file touched in this diff is just a styling change.
Reviewed By: ejanzer
Differential Revision: D17400387
fbshipit-source-id: e51884d8942ba01e7da1662ac24429070e53a504
Summary:
Similar to Android Venice impl, I plan to reuse old Timing native module because it's quite complex, and there's not much to gain from re-writing it. When we delete bridge access from it, we can remove any cruft, but IMO it's quite lean already.
The name of this class is a little confusing IMO, I originally had it because it was similar to `Timers.java` but then Emily renamed :p Here's the architecture drawn out:
{F209114665}
If anyone has a better name I'm all ears.
Reviewed By: RSNara
Differential Revision: D17376028
fbshipit-source-id: 066ae0b379cd00538021a1327a4dd63d5a828608
Summary:
Instead of relying on the bridge to do module setup, allow for regular initialization.
Instead of relying on the bridge to execute timers, allow for a delegate to do the work.
Reviewed By: RSNara
Differential Revision: D17375924
fbshipit-source-id: 83adabf8c962a5d90a4ea623618903cd9fb79a99
Summary: Fix for crash introduced by D17282188; doesn't cleanly revert, so just reverting this part
Reviewed By: JoshuaGross, RSNara
Differential Revision: D17505827
fbshipit-source-id: 3232285c0f15dabeb819f8806ad35d4ec83a1e53
Summary: Now that all the plumbing is done, this diff finally implements async method dispatch on the NativeModule thread.
Reviewed By: mdvacca
Differential Revision: D17480605
fbshipit-source-id: 992aab99954c488a0327144d84a1668a2b158d04
Summary:
Self explanatory.
1. **Existing:** We create the NativeModules thread in CatalystInstanceImpl.cpp.
2. D17422165: We wrap this thread in a `BridgeNativeCallInvoker`.
3. D17422164: We use `CatalystInstanceImpl::getNativeCallInvokerHolder()` to get a hold of the `BridgeNitiveCallInvoker` in Java.
4. D17422163: From Java, we pass this `CallInvokerHolder` to `TurboModuleManager`'s constructor.
5. **This diff:** `TurboModuleManager` then unwraps the `CallInvoker` from `CallInvokerHolder`, and passes it to all TurboModules in their constructor.
Reviewed By: PeteTheHeat
Differential Revision: D17422160
fbshipit-source-id: c0a76dfe5fdedac2e0e21f7a562bc7588dc190fb
Summary:
In the previous diffs, I:
1. D17422165: Created a `CallInvoker` for the NativeModules thread.
2. D17422164: Exposed this `CallInvoker` via `CatalystInstance.getNativeCallInvokerHolder()`.
In this diff, I:
1. Make TurboModuleManager accept the NativeModules thread `CallInvoker` as a constructor argument.
Reviewed By: PeteTheHeat
Differential Revision: D17422163
fbshipit-source-id: cbaac2fc06f7f726d89e0c545154123ad7410e62
Summary: CatalystInstanceImpl is responsible for creating the NativeModules thread. We therefore expose a method `getNativeCallInvokerHolder()` on this hybrid class to create and give us access to the `CallInvokerHolder` for the NativeModules thread.
Reviewed By: PeteTheHeat
Differential Revision: D17422164
fbshipit-source-id: 316423847518124115643549fa73a8533d493cd0
Summary: This abstraction will be used by TurboModules to schedule work on the NativeModules thread.
Reviewed By: PeteTheHeat
Differential Revision: D17422165
fbshipit-source-id: d5ca7837a0ecbcc2118813e1bafa6d445ba2ef3b
Summary:
## Motivation
The concept behind JSCallInvoker doesn't necessarily have to apply only to the JS thread. On Android, we need to re-use this abstraction to allow execution of async method calls on the NativeModules thread.
Reviewed By: PeteTheHeat
Differential Revision: D17377313
fbshipit-source-id: 3d9075cbfce0b908d800a366947cfd16a3013d1c
Summary:
This PR removes Java reflection use in ReactDrawerLayoutManager.java because we all use AndroidX and setDrawerElevation is available. Also adds NonNull annotations
## Changelog
[Android] [Changed] - cleanup DrawerLayoutAndroid
Pull Request resolved: https://github.com/facebook/react-native/pull/26497
Test Plan: RNTester is working as expected.
Differential Revision: D17488727
Pulled By: mdvacca
fbshipit-source-id: fd626e3e7aca3965f62c4c82a55c69e81facc61d
Summary:
We used to generate the documentation for the website but moved the docs to another repo.
There is some work on the docs to be able to ingest info from this repo in order to go back to generating API information. The current thinking is we will generate this JSON file and the website repo will pull it in to generate the docs.
I plan to make the script run on CI and fail if the generated file isn't updated, in a follow up PR.
Reviewed By: zackargyle
Differential Revision: D17183936
fbshipit-source-id: 99ce3fa5d7becc0ef20df5d439b175eedbe546f3
Summary:
We need to get rid of findNodeHandle calls so migrating scrollResponderScrollNativeHandleToKeyboard to take a ref to a host component.
I made this change with Flow, and tested by rendering UserJobApplicationForm
Reviewed By: mdvacca
Differential Revision: D17099280
fbshipit-source-id: 96af692006aace2c206f268f5416984b00f8a438
Summary:
The merge of https://github.com/facebook/react-native/issues/25451 added `xcshareddata` to the .gitignore file in `template`. Two xcscheme files in the `xcschemes` subfolder were still left in the template and should have been removed at the same time.
The project opens and builds fine without the xcscheme files both from command line and in Xcode.
## Changelog
[iOS] [Changed] - Remove ignored iOS schemes from template
Pull Request resolved: https://github.com/facebook/react-native/pull/26471
Test Plan:
Generate new project, remove files, verify that project builds, and opens correctly in Xcode.
Please review karanjthakkar satya164 kelset
Differential Revision: D17491748
Pulled By: cpojer
fbshipit-source-id: 391545293c2d09d52f78f56cd91cef5dcf036a9a
Summary:
This PR is extracts and reuses ANDROIDX_TEST_VERSION, and is part of Gradle script refactoring effort.
## Changelog
[Android] [Changed] - extract and reuse ANDROIDX_TEST_VERSION
Pull Request resolved: https://github.com/facebook/react-native/pull/26487
Differential Revision: D17488766
Pulled By: mdvacca
fbshipit-source-id: f1968ffc403074d78d792eb5cc773cc6366ad2d1
Summary:
This diff splits up the current `createTimer` method (which is used for setTimeout, setInterval, etc.) into two methods, `createTimer` and `createAndMaybeCallTimer`. The latter is what's used by the existing Timing native module, and it preserves the existing behavior of this function.
What's the difference? The current implementation of createTimer makes some assumptions about how it's called - namely, that it's called from JS asynchronously (using the bridge). Right now when you create a timer from JS, the JSTimers module passes in the timestamp for when the timer was created; in the native `createTimer`, we compare this timestamp to the current time, and if we find the timer has already expired, we immediately invoke the callback.
Presumably this is done because we don't know how much time has elapsed since when the timer was scheduled in JS, and we want to make sure that it's called as soon as possible. Of course, this also means that `setTimeout(0)` will be immediately invoked, too, without waiting for the next frame.
This all sounds fine, until we take a look at immediates. Immediates are currently implemented entirely in JS, and are called by the JS bridge; before returning control to native, we flush the immediates queue.
This means that the current behavior is: 1) `setImmediate()` is always invoked before `setTimeout(0)`; 2) `setTimeout(0)` is invoked as soon as possible, before the next frame.
However, this changes with bridgeless RN. With bridgeless RN, the native module methods are being replaced by C++ host functions, which are called synchronously. So if we keep the current logic in JavaTimerManager (where it checks if the timer has already expired), then `setTimeout(0)` will be invoked **before** immediates are called.
So the change that I'm making for bridgeless RN is to always wait until the next frame before calling timers. This preserves the order of immediates/timers, although it does mean that `setTimeout(0)` will no longer be called as soon as possible. Of the two options, this seems preferable.
Reviewed By: PeteTheHeat
Differential Revision: D17403144
fbshipit-source-id: 8230f6ebe56aa20bfcf2325177c7812bc8e9c2ec
Summary:
In Windows, if you clicked on a Switch component to toggle it, you could see it "shimmy" back and forth once before settling. The native Switch ends up toggling three times every time it's invoked.
`Switch.js` prevents the native switch from toggling to the new value by explicitly setting the switch to `this.props.value` when it receives an `onChange` event. The re-setting of the value wasn't fast enough to prevent the `Switch` from starting to toggle, causing the visual shimmy.
The solution is taken from `TextInput`. `TextInput.js` stores `_lastNativeText` when it receives an `onChange` event. In `componentDidUpdate`, it puts `this.props.text` back on the native textbox if the value of `this.props.text` isn't the same as `_lastNativeText`, which is how it ensures that it is a controlled component. Porting this to the `Switch` results in only one toggle happening per invoke, removing the shimmy, while preserving the controlled component behavior.
This bug is not visible on Android or iOS, only Windows, however the code causing the bug was in `Switch.js` and it seems reasonable to avoid changing the value of the native switch excessively.
## Changelog
[General] [Fixed] - Fix excessive toggles on the Switch component
Pull Request resolved: https://github.com/facebook/react-native/pull/26496
Test Plan: Used RNTester on Android and iOS to test the Switch component and made sure that all scenarios behave as expected visually. Also ensured through the debugger that the value of the native switch is only being changed once, instead of three times.
Reviewed By: TheSavior
Differential Revision: D17468905
Pulled By: JoshuaGross
fbshipit-source-id: 92bf511510306968c3573ee4eed6df009850fd77
Summary:
This change restores the possibility of injecting custom root views via ReactAcitivtyDelegate. It has been used by react-native-gesture-handler library in order to replace default root view with a one that'd route touch events to gesture-handler internal pipeline.
The regression happened in d0792d4b8a where new `ReactDelegate` was introduced to provide support for rendering react native views in both Android fragments and activities. As a part of that change the logic responsible for creating root view has been moved from `ReactActivityDelegate` to `ReactDelegate` rendering `ReactActivityDelegate.createRootView` unused – that is there is no code path that leads to this method being called. Instead `ReactDelegate.createRootView` method has been added which now plays the same role. The custom root view injection was relying on overwriting that method and hence the method is no longer referenced overwriting it has no effect. Following the logic migration out of `ReactActivityDelegate` into `ReactDelegate` we could potentially now start overwriting methods of `ReactDelegate`. However when working with Android's activities in React Native we can only provide an instance of `ReactActivityDelegate` and in my opinion it does not make too much sense to expose also a way to provide own instance of `ReactDelegate`.
The proposed fix was to route `ReactDelegate.createRootView` to call `ReactActivityDelegate.createRootView` and this way regaining control over root view creation to `ReactActivityDelgate`. The change of the behavior has been implemented by subclassing `ReactDelegate` directly from `ReactActivityDelegate` and hooking the aforementioned methods together. Thanks to this approach, the change has no effect on `ReactDelegate` being used directly from fragments or in other scenarios where it is not being instantiated from `ReactActivityDelegate`.
This fixes an issue reported in https://github.com/kmagiera/react-native-gesture-handler/issues/745 and discussed on 0.61 release thread: https://github.com/react-native-community/releases/issues/140#issuecomment-532235945
## Changelog
[Internal] [Fixed] - Allow for custom root view to be injected via ReactActivityDelegate
Pull Request resolved: https://github.com/facebook/react-native/pull/26495
Test Plan:
1. Run RNTester, take layout snapshot, see the react root view being on the top of view hierarchy.
2. Run gesture-handler Example app (or some other app that overwrites ReactActivityDelegate.createRootView method), on layout snapshot see custom root view being used.
Differential Revision: D17482966
Pulled By: mdvacca
fbshipit-source-id: 866f551b8b077bafe1eb9e34e5dccb1240fa935e
Summary:
The next step to making our existing timers logic usable outside of the context of the native module. This diff removes the bridge access through ReactContext in JavaTimerManager, and instead relies on a delegate that implements the JSTimers interface. I'm reusing the JSTimers interface for convenience even though it extends JavaScriptModule, which I don't plan on using for bridgeless RN.
Also changing from ReadableArray to ReadableNativeArray so that it can be directly accessed from C++.
Reviewed By: PeteTheHeat
Differential Revision: D17282188
fbshipit-source-id: 5c5e0b12a2250334e96885c220feb52146e57c83
Summary:
Decoupling the logic for managing timers from the native module interface in TimingModule. I'm doing this so we can more easily share this logic with bridgeless RN, which won't use a native module for timers but instead will define the bindings with JSI.
This diff just moves things around and doesn't change any of the behavior.
Reviewed By: PeteTheHeat
Differential Revision: D17282187
fbshipit-source-id: ef54254dd0c7e2f6e294e9ae5a7d4b010f98de2e
Summary: Most of our other native modules end in 'module', so let's update Timing to match.
Reviewed By: RSNara
Differential Revision: D17260848
fbshipit-source-id: 808b4d370a7036a247724fda5ab7210ac985476b
Summary:
If you try to use ART components with fabric, their transform is causes crash (stack trace P108110438). You can see this crash if you use RCTVideo component in fabric and tap video to reveal slider.
The cause of crash is mismatch of formats between what is expected for transform and what is being sent.
In this diff we add a check to see whether the configuration is of expected type.
Reviewed By: shergin
Differential Revision: D17181838
fbshipit-source-id: c4f3c920281a2e7f58ff0ffe1d0ec2af8249a16c
Summary:
To help cache Pods artifacts for Sandcastle test run, create a `__generated__` dir under RNTester/Pods, which will contain the normally-top-level files produced by `pod install`. The files will then be symlinked by the script.
allow-large-files
Reviewed By: axe-fb
Differential Revision: D17470686
fbshipit-source-id: 50e4c57e913e2884eed27db94c50181fe4632133
Summary: This diff fixes two issues with the JNI integration of YogaLogger#log. (1) The YogaLogger class descriptor was missing a semicolon. This causes a ClassNotFoundException whenever you try to call the log method from C++. (2) The C++ signature for the class was using YogaNodeJNIBase as an arg but the Java signature was using YogaNode. This causes a MethodNotFoundException whenever you try to call the method after fixing problem 1.
Reviewed By: astreet
Differential Revision: D17439957
fbshipit-source-id: be3c16512558050265565b3688fb09a7da31b9b2
Summary: These subdirs are generated by CocoaPods, they shouldn't be checked in normally. Note that this must be explicitly listed for FB-CI compatibility.
Reviewed By: axe-fb
Differential Revision: D17469656
fbshipit-source-id: 05b023d3f0fa72ddd7cb301cdaf03eabd4f9a4d8
Summary: Removed Flipper deps from RNTester for now, since it's not compatible with FB CI yet.
Reviewed By: axe-fb
Differential Revision: D17465404
fbshipit-source-id: 581f113506dc9dbd345c404a802eb1b622f68ab7
Summary: This was already deprecated, but without a message.
Reviewed By: zackargyle, ejanzer
Differential Revision: D17180347
fbshipit-source-id: 44aa5d1821e56f7600033e82062c4661fe663471
Summary:
This is a easy change in ReactEventEmitter that refactors the TAG used by this class to log events.
This is a follow up of D17422611
Reviewed By: makovkastar
Differential Revision: D17437034
fbshipit-source-id: 9974a244b24b04315c6a328696954b7acf7efbfd
Summary:
Reland https://github.com/facebook/react-native/pull/24767
The commit had to be reverted because it caused a crash when using remote debugging in chrome. This is normal since jsi is not available in that environment. The crash was caused by `jsContext.get()` being 0, then being dereferenced later in c++. We can simply skip initializing the blob collector in this case.
This also includes the fix from https://github.com/facebook/react-native/issues/25720 to fix a crash when using hermes.
## Changelog
[Android] [Fixed] - Release underlying resources when JS instance is GC'ed on Android
Pull Request resolved: https://github.com/facebook/react-native/pull/26155
Test Plan:
Test using RN tester with jsc and hermes
Test remote debugging
Reviewed By: mdvacca, fred2028
Differential Revision: D17072644
Pulled By: makovkastar
fbshipit-source-id: 079d1d43501e854297fbbe586ba229920c892584
Summary:
React Native components need a mechanism to specify their value to assistive technologies. This PR adds the notion of accessibilityValueDescription-- a property which either contains a textual description of a component's value, or for range-based components, such as sliders and progress bars, it contains range information (minimum, current, and maximum).
On iOS, the range-based info if present is converted into a percentage and added to the accessibilityValue property of the UIView. If text is present as part of the accessibilityValueDescription, it is used instead of the range-based information.
On Android, any range-based information in accessibilityValueDescription is exposed in the AccessibilityNodeInfo's RangeInfo. Text which is part of accessibilityValueDescription is appended to the content description.
## Changelog
[GENERAL] [Change] - add accessibilityValuedescription property.
Pull Request resolved: https://github.com/facebook/react-native/pull/26169
Test Plan: Added two new accessibility examples to RNTester, one which uses text and another which uses range-based info in accessibilityValueDescription. Verified that they both behave correctly on both Android and iOS.
Differential Revision: D17444730
Pulled By: cpojer
fbshipit-source-id: 1fb3252a90f88f7cafe1cbf7db08c03f14cc2321
Summary:
ReactAndroid Gradle was failing mysteriously with error below, because it was trying to read values from **android** when it wasn't configured completely.
```java
extensionSupplier.get()!!.compileSdkVersion must not be null
```
or
```java
compileSdkVersion is not specified.
```
It is happening because **buildReactNdkLib** task was created and configured eagerly. So this PR changes some tasks to be configured lazily, and reads values from **android** when ready. Also remove ANDROID_NDK variable check because android gradle plugin doing it automatically.
## Changelog
[Android] [Changed] - lazily configure ReactAndroid gradle tasks
Pull Request resolved: https://github.com/facebook/react-native/pull/26314
Test Plan: ./gradlew ReactAndroid:tasks run without errors, while master throws exception.
Differential Revision: D17177945
Pulled By: cpojer
fbshipit-source-id: c7a165092157d2059f946da70b801d1a475d4b8c
Summary:
Remove YogaNode.create() from the abstract class after we made sure nothing uses it anymore
This is the final stage to make `YogaNode` a pure class without JNI references
Reviewed By: SidharthGuglani
Differential Revision: D17280571
fbshipit-source-id: bd0eb138f7a6a9de8988fc0a7b90badbf635dac5
Summary:
Split YogaConfig into the same way YogaNode is split today.
Into an abstract class defining the interface, and actual JNI implementation
Reviewed By: SidharthGuglani
Differential Revision: D17266404
fbshipit-source-id: 3d5d6aa65c55cfa61d47c662d140cdce6dcb0ea1
Summary: This function was deprecated in Dec 2016. It has no callsites at FB and should be deleted.
Reviewed By: zackargyle, ejanzer
Differential Revision: D17180174
fbshipit-source-id: de3ab78c469220b629ef7f6773d60507959f6db6
Summary:
The files autogenerated by `scripts/generate-rncore.sh` aren't to be committed. This pull request adds them to the repo's `.gitignore`
## Changelog
[Internal] [Changed] - Add codegen generated files to gitignore
Pull Request resolved: https://github.com/facebook/react-native/pull/26479
Test Plan: The files generated by `generate-rncore.sh` are no longer added when you run `git add .`
Differential Revision: D17439794
Pulled By: TheSavior
fbshipit-source-id: 54a2e07aefc5fd187ba5eb8de0c2cd8b69ee4053
Summary:
This pull request makes the following changes to the script `scripts/generate-rncore.js`:
* Adds a missing argument to the call of `generate-tests.js`
* Ran `chmod +x generate-rncore.sh` so the script is executable
## Changelog
[Internal] [Fixed] - Updated `generate-rncore.sh` for recent versions of codegen
Pull Request resolved: https://github.com/facebook/react-native/pull/26477
Test Plan: `(cd scripts && ./generate-rncore.sh)` works perfectly now.
Differential Revision: D17439772
Pulled By: TheSavior
fbshipit-source-id: 141efc54aa45aa38dc537f65e425959666f33b3a
Summary:
The concept of `EventBeat::Owner` was introduced in D17128549, this diff implements some missing pieces of that.
After the change, AsyncEventEmitter will check the existence of the "owner" (which is EventDispatcher) which guarantees that the rest of the pipeline is still alive (the validity of Runtime is guaranteed by RuntimeExecutor separately).
The overall workflow is described in D17128549.
Reviewed By: JoshuaGross
Differential Revision: D17410738
fbshipit-source-id: a1ae8e09600546874cdc7c622b3d884b71c5b48d
Oleksandr Melnykov
Samuel Susla
Amir Shalem
Peter Argany
Kevin Gozali
Emily Janzer
Mike Vitousek
Ramanpreet Nara
Dulmandakh
Eli White
Frieder Bluemle
Janic Duplessis
Ruriko Araki
Krzysztof Magiera
Uts Sikder
Alexander Kawrykow
David Vacca
sunnylqm
Marc Mulcahy
empyrical
Valentin Shergin
