Граф коммитов

22504 Коммитов

Автор SHA1 Сообщение Дата
Joshua Gross 88c3090066 Correct LayoutMetrics comparison and make debuggable
Summary:
Allow conversion of LayoutMetrics to DebuggableString.

We also skipped a field in comparison. It probably isn't impactful in terms of production issues, but still wasn't correct.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D27709451

fbshipit-source-id: 987fc2de0a4562a295d6cbeffdd922cbf056b811
2021-04-14 09:41:41 -07:00
Brian Vaughn 60a18c138c Don't disconnect DevTools WebSocket connection on Cmd+D
Summary:
When the React Native Cmd+D menu is opened, something re-runs module initialization code (including DevTools backend initialization) which recreates the `WebSocket` and kills any already-connected frontend.

It's not clear to me why this is done. (Intentional? Accident?) But it makes it difficult to connect the React Native Inspector and DevTools together without multiple reloads. This Diff prevents the Cmd+D menu from killing the `WebSocket` connection as a workaround. A better long-term fix would (probably) be to not eagerly re-run these modules.

## Changelog

[General] [Fixed] - Don't disconnect DevTools WebSocket connection on Cmd+D

Reviewed By: fkgozali, sammy-SC

Differential Revision: D27742376

fbshipit-source-id: 60ab3e4763da6b055c28c7aafc6d460e7f4a601d
2021-04-14 07:42:38 -07:00
CodemodService FBSourceBuckFormatLinterBot 73b9f78e33 Daily `arc lint --take BUCKFORMAT`
Reviewed By: zertosh

Differential Revision: D27761011

fbshipit-source-id: 6231e04819b758d0daa1c78b412742be9b23cf3f
2021-04-14 04:05:56 -07:00
Samuel Susla 06753d431a Add expiration date to Task and use it to determine priority
Summary:
Changelog: [internal]

To prevent starvation, this diff implements expiration time as a way to order tasks in priority queue. This stops higher priority tasks from preventing lower priority tasks from running. The same mechanism is implemented in [JavaScript's scheduler](https://github.com/facebook/react/blob/master/packages/scheduler/src/forks/SchedulerNoDOM.js).

Reviewed By: mdvacca

Differential Revision: D27707887

fbshipit-source-id: 3dc734c856a166ef5c17c5045ebd429565ba79f0
2021-04-14 02:53:24 -07:00
Samuel Susla 240588b6d4 Implement RuntimeScheduler::now
Summary:
Changelog: [internal]

Implement RuntimeScheduler::now and exposite it to JavaScript. JavaScripts expects miliseconds and is using `performance.now()` call to get this value.

More about `performance.now()`: https://developer.mozilla.org/en-US/docs/Web/API/Performance/now
JavaScript implementation in Scheduler: https://github.com/facebook/react/blob/master/packages/scheduler/src/forks/SchedulerNoDOM.js#L71-L82

Reviewed By: JoshuaGross

Differential Revision: D27675512

fbshipit-source-id: bce5ac700e71b1722cd280dfbdd15e141783a3a5
2021-04-14 02:53:24 -07:00
Samuel Susla 52f1d54509 Add implementation for requestPaint
Summary:
Changelog: [internal]

requestPaint is unimplemented on JavaScript scheduler:

https://github.com/facebook/react/blob/master/packages/scheduler/src/forks/SchedulerNoDOM.js#L445

Reviewed By: mdvacca

Differential Revision: D27651947

fbshipit-source-id: 1e3cece8cbcd330f2408887ceb283ca61374f5bd
2021-04-14 02:53:23 -07:00
Samuel Susla cc3e87c45b Implement RuntimeScheduler::getShouldYield
Summary:
Changelog: [internal]

Implement RuntimeScheduler::getShouldYield and expose it through JSI.
For now we are only returning `false`. The value is backed by atomic_bool and in the future we will be able to indicate that React should yield to native.

JavaScript implementation:
https://github.com/facebook/react/blob/master/packages/scheduler/src/forks/SchedulerNoDOM.js#L439-L441

Reviewed By: JoshuaGross

Differential Revision: D27648579

fbshipit-source-id: b9313e2efbd9daae8975357df9de803f24a35e89
2021-04-14 02:53:23 -07:00
David Vacca aee07e1203 Integrate react_native_asserts into mapbuffer
Summary:
Integrate react_native_asserts into mapbuffer

changelog: [internal] internal

Reviewed By: JoshuaGross

Differential Revision: D27753092

fbshipit-source-id: dbeb7f140f3096c8153e2f6bced4e4d9d88b48b8
2021-04-13 21:32:17 -07:00
Kudo Chien e57de5f32f Fix CI "Build Tests: Android Instrumentation Tests" errors (#31352)
Summary:
To fix [the CI error](https://app.circleci.com/pipelines/github/facebook/react-native/8708/workflows/d584348e-941f-4653-96c2-46375894dfaa/jobs/196410)
  There are two errors:
  `error: undefined reference to '__android_log_write'` which solved by adding `-llog` linker flag.

  `ld: error: cannot find -lc++` which workaround by static linking.
  For the root cause, I am thinking that is after [NDK r19](https://developer.android.com/ndk/guides/other_build_systems),
  the `-target` should specificy api level.
  However, buck does not add this accordingly, e.g. `-target armv7-none-linux-androideabi`
  Given wrong target will make NDK to have `cannot find -lc++` error.
  The workaround is to use static linking.
  Since it was an oss_cxx_library, the change should not have impact to Facebook internal testing.

## Changelog

[Internal] [Fixed] - Fix CI "Build Tests: Android Instrumentation Tests" errors

Pull Request resolved: https://github.com/facebook/react-native/pull/31352

Test Plan: Make CI green

Reviewed By: JoshuaGross

Differential Revision: D27757838

Pulled By: fkgozali

fbshipit-source-id: 8f9c80a89c6240938218abacb8a82e3e2e71adbc
2021-04-13 21:25:31 -07:00
Samuel Susla 08ef1df1ba Implement RuntimeScheduler::cancelTask
Summary:
Changelog: [internal]

Implement RuntimeScheduler::cancelTask and expose it through JSI.

JavaScript implementation:
https://github.com/facebook/react/blob/master/packages/scheduler/src/forks/SchedulerNoDOM.js#L384-L397

Reviewed By: mdvacca

Differential Revision: D27648071

fbshipit-source-id: 91ae92b336017596fb658831824e971c7e047cd2
2021-04-13 01:55:04 -07:00
Samuel Susla 3c14c196ca Add return value to RuntimeScheduler unstable_scheduleCallback
Summary:
Changelog: [internal]

unstable_scheduleCallback needs to return reference to the created task so it can be cancelled later.

Reviewed By: mdvacca

Differential Revision: D27622779

fbshipit-source-id: 54160015c7f98e123d08c2e13efac4f498d3ba5e
2021-04-13 01:55:04 -07:00
Samuel Susla 2779129434 Add minimal implementation of RuntimeScheduler::scheduleTask
Summary:
Changelog: [internal]

Add minimal implementation of schedule task. More features and proper scheduling will be added later.

Reviewed By: mdvacca

Differential Revision: D27622138

fbshipit-source-id: b2e4623d38e7217290a6a3c59ccc10a1c13e3a4f
2021-04-13 01:55:04 -07:00
Samuel Susla 71b5178230 Make glog exported depencency of debug module
Summary:
Changelog: [internal]

`glog` needs to be exported dependency because it is used in public headers.

Reviewed By: mdvacca

Differential Revision: D27617632

fbshipit-source-id: 91aa27b641286002a80a8cd5ef2e6fe6c266b452
2021-04-13 01:55:03 -07:00
Samuel Susla 8d5c22edfd Add runtime scheduler priorities
Summary:
Changelog: [internal]

Add runtime scheduler priorities

Reviewed By: JoshuaGross

Differential Revision: D27618305

fbshipit-source-id: 95e4e02f3473acb41bca0c22df7b271a8d710f34
2021-04-13 01:55:03 -07:00
Mike 1b0683533a Android: Fix switch ripple color (#30685)
Summary:
fix https://github.com/facebook/react-native/issues/22370

Use `RippleDrawable` to change ripple color.
According to the [document](https://developer.android.com/reference/android/graphics/drawable/RippleDrawable?hl=en), `RippleDrawable` is added in API 21, so warped the code in the `if` statement for version checking.

## Changelog

<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->

[Android] [Fixed] - Fix wrong ripple color on Switch component

Pull Request resolved: https://github.com/facebook/react-native/pull/30685

Test Plan:
1. Create an empty app with react-native 0.63.4, copy&paste the App.js from issue https://github.com/facebook/react-native/issues/22370
2. Apply the code for fixing to `node_modules/react-native/ReactAndroid/src/main/java/com/facebook/react/views/switchview/ReactSwitch.java`
3. Configure the project to let it Build from ReactAndroid
4. Check if ripple color has changed correctly
5. Use different color on each state and check if it is working

Test device: Android emulator, Pixel 4, API 30

## Screenshot

### Before
Ripple is always in default color

https://user-images.githubusercontent.com/48589760/103573532-5b4cec80-4f09-11eb-96d7-f75efa6779d9.mov

### After
Ripple color has changed with thumb color

https://user-images.githubusercontent.com/48589760/103573216-d95cc380-4f08-11eb-98fb-494e28c12a9f.mov

Check different color on each state

https://user-images.githubusercontent.com/48589760/103573227-de217780-4f08-11eb-8992-ede5d1dd89c1.mov

Reviewed By: mdvacca

Differential Revision: D27636802

Pulled By: lunaleaps

fbshipit-source-id: fa23cc8b51c642e5e5d9c73371c8ccef3741fd14
2021-04-12 13:57:27 -07:00
Andrei Shikov a17e3cf893 Avoid mounting tree on mode change if it wasn't commited
Summary:
Changelog: [Internal]

Calls to `surfaceHandler.start()` and `setDisplayMode(DisplayMode::Visible)` in quick succession on different threads can cause a race condition between mount and commit operations.

The mountingCoordinator will try to mount an empty revision without any commits causing it to fail with:
```
TransactionTelemetry.cpp:108: function getCommitStartTime: assertion failed (commitStartTime_ != kTelemetryUndefinedTimePoint)
```
which is called from [Binding.cpp](https://www.internalfb.com/intern/diffusion/FBS/browse/master/xplat/js/react-native-github/ReactAndroid/src/main/java/com/facebook/react/fabric/jni/Binding.cpp?lines=791-791&blame=1).

This change avoids this initial commit by verifying we had at least 1 revision commited before mounting it.

Reviewed By: sammy-SC

Differential Revision: D27430174

fbshipit-source-id: d208d55f02cd218a316d6fea62d0106c2bcb4be8
2021-04-12 13:17:52 -07:00
Andrei Shikov 214aaf2703 Move surface handler registration to Binding.cpp
Summary:
Changelog: [Internal]

Inverts registration of a SurfaceHandler with the scheduler: instead of passing a scheduler to the SurfaceHandlerBinding, we can now query the SurfaceHandler and register it in place.

Reviewed By: JoshuaGross

Differential Revision: D27624541

fbshipit-source-id: db5d7f1375fad72a805309a3fcd5a33080e4a4a7
2021-04-12 13:17:52 -07:00
Andrei Shikov 5cba7c0ce7 Add a way to prerender the surface
Summary:
Changelog: [Internal]

Links APIs in Fabric and Venice to create a surface without a view and mount it separately when surface is started the usual way.

Reviewed By: mdvacca

Differential Revision: D27339365

fbshipit-source-id: d1b674ce856957465eb6f3a5d7f26eb0ab625353
2021-04-12 13:17:52 -07:00
Nadiia D d65b5895ce Rewrite Modal to a functional component and add gating for the change
Summary:
Changelog:
[Internal][Added] - Use injected Modal if set

Due to Modal uses AppContainer in a dev env, in the StrictMode we'll get warnings about legacy context API usage from inside the AppContainer.

It's a gnarly change to get rid of that legacy context so I'll be following up with additional code change prep steps towards the eventual removal of the legacy context.

Reviewed By: lunaleaps

Differential Revision: D27611218

fbshipit-source-id: f79475845e763527fff9ecfdbf3e581c4666e015
2021-04-12 12:47:00 -07:00
Tim Yung cb6cbd12f8 EventEmitter: Deprecate `removeSubscription`
Summary:
Deprecates `EventEmitter#removeSubscription`. This required temporarily introducing a new `__removeSubscription` method that is only invoked by `EmitterSubscription`. This is necessary so that we do not completely break usages of `EventEmitter` that are supplying constructor arguments (which is also deprecated, but still supported until the next release).

Calling this method will now cause a warning to appear with instructions to instead invoke `remove()` on the subscription itself.

Lastly, changed `console.error` deprecation notice to instead use `console.warn`. This is in line with the principle that errors are "broken today" and warnings will be "broken tomorrow".

Changelog:
[General][Deprecated] - `EventEmitter#removeSubscription` is now deprecated.

Reviewed By: rubennorte

Differential Revision: D27704279

fbshipit-source-id: 581f5b2ab46b1bcfc1d20898b3d3392988dccbd5
2021-04-12 12:43:07 -07:00
Tim Yung 62934e555d EventEmitter: Cleanup Redundant Internal Types
Summary:
Cleans up some minor redundant internal types in `_EventEmitter.js`.

Changelog:
[Internal]

Reviewed By: rubennorte

Differential Revision: D27712301

fbshipit-source-id: e6affcb7948e0f47a1775b74b12f59ec2a6abddb
2021-04-12 12:43:07 -07:00
Tim Yung 14f7a2b707 EventEmitter: Deprecate Constructor Argument
Summary:
Deprecates the constructor argument to `EventEmitter`.

It was only ever used by React Native to instantiate a `NativeEventEmitter` with the same "vendor" as `RCTDeviceEventEmitter`, which was a gross violation of encapsulation that led to an overcomplicated implementation of `EventEmitter`. I am now untangling that mess.

Changelog:
[General][Deprecated] - It is now deprecated to pass a constructor argument to `EventEmitter(...)`.

Reviewed By: rubennorte

Differential Revision: D27704182

fbshipit-source-id: 102f26a8a9c029f0e7a1346dc2f2d9f2548d6a42
2021-04-12 12:43:07 -07:00
Madhav Gharmalkar 9d263aacf4 Refactor React Native SectionList component to a functional component
Summary:
Changelog:
[Internal] - Refactors SectionList component to be a functional component instead of a Class component

Closes #31322

Reviewed By: lunaleaps

Differential Revision: D27681457

fbshipit-source-id: ef0e68dd4bc91e83b40c55a4a959f27e69292964
2021-04-12 12:13:32 -07:00
Samuel Susla 8f4aed6386 Fix race inside ScrollView._inputMeasureAndScrollToKeyboard
Summary:
Changelog: [internal]

For React Native classic the behaviour is identical.

# Problem

`ScrollView.scrollResponderScrollNativeHandleToKeyboard` is broken in new React Native renderer. The behaviour depends on race between two events, `measureLayout` and `keyboardWillShow` event. In the new renderer, `measureLayout` always wins because it is a synchronous call, unlike in React Native classic.

To fix this we can just delay execution by wrapping it in `setTimeout`, which puts it on the back of the queue.

Reviewed By: JoshuaGross

Differential Revision: D27705883

fbshipit-source-id: 7556f86978ca3ccd2fddf1eef2435af26b54f585
2021-04-12 09:48:37 -07:00
Andrei Shikov ea1ff374de Assign batch number to only batched animated instructions
Summary:
Changelog: [Internal]

`NativeAnimatedModule` on Android currently enforces all animation operations to be processed in batches to ensure that all associated operations are processed at the same time.
Some operations, however, can be triggered outside of the batching calls (e.g. when using `Animated` for tracking touches `PanResponder`), and they are not processed until the next batch.

This change tracks if we are currently processing a batch and doesn't assign a batch number if an operation was triggered outside of `startOperationBatch`/`finishOperationBatch` pair.

Reviewed By: mdvacca

Differential Revision: D27682424

fbshipit-source-id: 2ea8737c353c81557fa586b15aa5760db3e8813f
2021-04-12 09:18:47 -07:00
Rubén Norte f5502fbda9 Use native module passed to NativeEventEmitter on Android
Summary:
## Context

In native modules implementing an event emitter, we can wait for JS to subscribe to an event before making the subscription to the right native API in the native module. This is only supported on iOS at the moment and we want to support it on Android too, so we can manage resources more efficiently and avoid custom code to do this on Android, like this:

https://www.internalfb.com/intern/diffusion/FBS/browse/master/xplat/js/RKJSModules/public/Dating/Profile/ProfileView/ProfileGemstoneProfileView.js?commit=165ad219e6bf&lines=302-304

The way this works now is by creating instances of `NativeEventEmitter`, where we pass a reference to the native module that needs to be notified when there are new subscriptions. We have explicit code to ignore this native modules in all platforms except for iOS:
https://www.internalfb.com/intern/diffusion/FBS/browsefile/master/xplat/js/react-native-github/Libraries/EventEmitter/NativeEventEmitter.js?commit=5a1e671453465e844dd851c458cb2467a2db5d03&lines=44-52

## Changes

This removes the check for iOS from `NativeEventEmitter` so we also try to use the native module to notify subscriptions on Android.

We have migrated all existing code passing a native module to `NativeEventEmtiter` to only pass it on iOS, so we don't change this behavior in existing code.

Any other existing code using this API is most likely fine too. It didn't work before so the expectation is that the native module wouldn't be implemented on Android anyway.

Changelog: [Android][Changed] - Modified `NativeEventEmitter` to also use the passed native module to report subscriptions on Android

Reviewed By: yungsters

Differential Revision: D27500994

fbshipit-source-id: ef82da04020fb08cd0ea4f1cfffd1da6453ab0b9
2021-04-12 06:27:20 -07:00
Rubén Norte 38cfa93775 Migrate remaining modules using NativeEventEmitter to only pass the native module on iOS
Summary: Changelog: [Internal]

Reviewed By: fred2028

Differential Revision: D27501270

fbshipit-source-id: 1d447017e862baf834310650778f2abbff50945c
2021-04-12 06:27:20 -07:00
Rubén Norte 87517aeecb Codemod usages of NativeEventEmitter in react-native-github to only pass a native module on iOS
Summary: Changelog: [Internal]

Reviewed By: yungsters

Differential Revision: D27500993

fbshipit-source-id: 99b33e25daf46b7d1debc6435dd32505ad2cf855
2021-04-12 06:27:20 -07:00
David Vacca b28ddede7b Transfer 'DisplayMode' value from Native -> JS
Summary:
This diff adds a new variable called "DisplayMode" into SurfaceHandler.cpp and FacebookAppRouteHandler.js. The purpose of DisplayMode is for the native pre-render system to notify React that the a surface is either being "pre-rendered" or "rendered"

When the surface is being "pre-rendered" (displayMode == "SUSPENDED"), react will create and commit React Trees, but it will not execute use-effect callbacks

When the surface is being "rendered" (displayMode == "VISIBLE"), react will create and commit React Trees and it will not execute all use-effect callbacks that weren't executed during "pre-rendering"

By default surfaces are going to be rendered with displayMode == "VISIBLE".

This diff should not create any change of behavior for now, this is the infra required to integrate the new offScreen API the react team is working on for pre-rendering system

changelog: [internal] internal

Reviewed By: yungsters

Differential Revision: D27614664

fbshipit-source-id: f1f42fdf174c2ffa74174feb1873f1d5d46e7a95
2021-04-12 00:05:43 -07:00
David Vacca bdb9a1e094 Add displayMode parameter into startSurface and setSurfaceProps methods
Summary:
This diff extends startSurface and setSurfaceProps methods with the new parameter called displayMode

changelog: [internal] internal

Reviewed By: yungsters

Differential Revision: D27669847

fbshipit-source-id: c2ddb690ca897e46e00f07b491b91bb2bc8e847d
2021-04-12 00:05:43 -07:00
David Vacca 2793bba278 Move DisplayMode out of SurfaceHandler
Summary:
This diff moves DisplayMode out of SurfaceHandler, this is necessary in order to use it from react/uimanager package

changelog: [internal] internal

Reviewed By: ShikaSD

Differential Revision: D27669846

fbshipit-source-id: 274869d8f2907b1b159f51240440acece09a746f
2021-04-12 00:05:43 -07:00
David Vacca 84c70b2a7f Introduce setDisplayMode method in SurfaceHandler
Summary:
This diff introduces the new setDisplayMode java method in SurfaceHandler classes

changelog: [internal] internal

Reviewed By: JoshuaGross

Differential Revision: D27607585

fbshipit-source-id: aac0def4136cf70e99ef7b20eba85e3e975b72d9
2021-04-12 00:05:43 -07:00
David Vacca e7b52d7b0b Update initial props when DisplayMode changes in Fabric
Summary:
This diff updates initial props when DisplayMode changes in Fabric. This method will be called during pre-rendering.

changelog: [internal] internal

Reviewed By: JoshuaGross

Differential Revision: D27607586

fbshipit-source-id: 7625943d57a786d6dfe30dd893e27704f51826d2
2021-04-12 00:05:43 -07:00
David Vacca 680dd36fd1 Introduce new Fabric API setSurfaceProps
Summary:
This diff introduces a new fabric API called setSurfaceProps that will be used to call the new JS api "setSurfaceProps"

changelog: [internal] internal

Reviewed By: sammy-SC

Differential Revision: D27607588

fbshipit-source-id: 36a19f728af244d7e72687d9305b1c568e2b8ec6
2021-04-12 00:05:43 -07:00
David Vacca b5e2e1d52d Expose setSurfaceProps API in JS
Summary:
This diff introduces the new function "setSurfaceProps" in SurfaceRegistry and AppRegistry

This new method will be used to update initialProps of a surface at the root level. In the near future this will be useful to integrate the OffScreen API component in pre-rendering

changelog: [internal] internal

Reviewed By: JoshuaGross

Differential Revision: D27607587

fbshipit-source-id: 3cc58c51924feb68f6a24bf762986c57f9a245ae
2021-04-12 00:05:43 -07:00
Joshua Gross c91e32b050 Differ: introduce breadcrumb logging
Summary:
Introduce a new debugging mechanism for the debugger. Outside of debug mode (you must defined `DEBUG_LOGS_BREADCRUMBS` manually to enable this feature) it will have no cost or binary size.

When the debug mode is enabled, it allows you to trace the call stack to trace what the differ is doing, making logs more useful.

Motivation: tracking down a tricky bug caught by D27585136 which originates in the differ.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D27667885

fbshipit-source-id: ef75a9a1c8890f9bbe3e5b2e8a8ffcde92fb22c2
2021-04-09 10:30:15 -07:00
Ramanpreet Nara c4c34a1237 Delete RCTTurboModuleManagerDelegate getTurboModule:initParams
Summary:
D27316129 made it mandatory for all RCTTurboModules to have a getTurboModule: method. So, there's no need to keep the getTurboModule:initParams method in RCTTurboModuleManagerDelegate. So, to simplify the TurboModule infra, this diff gets rid of that TurboModuleManager delegate method.

Changelog: [iOS][Removed] - Delete RCTTurboModuleManagerDelegate getTurboModule:initParams

Reviewed By: fkgozali

Differential Revision: D27316873

fbshipit-source-id: c0b8449c6088bf08f17ba9a8d1c2cb644e5a242d
2021-04-08 21:15:53 -07:00
Ramanpreet Nara e0b8f5080f Make RCTTurboModule getTurboModule: required
Summary:
## Rationale
There are two ways to associate NativeModule ObjC objects with ObjCTurboModule jsi::HostObjects:
1. Via the NativeModule ObjC class's `getTurboModule:` method.
2. Via the TurboModule manager delegate's getTurboModule:initParams: method.

There's no good reason to support both options. So, this diff stack removes 2, and make 1 mandatory for all RCTTurboModules. Not only will this simplify the infra, but it should also help eliminate a class of runtime errors in the TurboModule standalone app migration: you forget to implement the getTurboModule: method.

Changelog: [iOS][Changed] - Make RCTTurboModule getTurboModule: required

Reviewed By: PeteTheHeat

Differential Revision: D27316129

fbshipit-source-id: baccd155b8c191d0f961b316db552bdfdbeb0a97
2021-04-08 21:15:53 -07:00
Ramanpreet Nara 3f38186b78 Codemod: Give legacy cxx and ObjC-only NativeModules a getTurboModule: method
Summary:
We're making the getTurboModule: method required for all classes that conform to RCTTurboModule.

Many of our ObjC-only and Cxx NativeModules don't implement this method. This diff implements a getTurboModule: method on all those modules that returns nullptr.

**Question:** Why is it fine to make ObjC-only NativeModules return nullptr from their getTurboModule: method?
- Because they're only accessed from ObjC, and should appear as null on the JavaScript side. Longer term, these NativeModules will also go away.

**Question:** Why is it fine to make Cxx NativeModules return nullptr from getTurboModule: method?
- Because after D27316872, the TurboModuleManager checks if the module is a CxxModule first. If it is, we do an early return, and never call the module's getTurboModule: method.

Changelog: [Internal]

Reviewed By: JoshuaGross

Differential Revision: D27316871

fbshipit-source-id: bc693f2927ab3b0de24e6e9e7699390ec0f7d729
2021-04-08 21:15:52 -07:00
Ramanpreet Nara 6a5e98a84c Stop calling getTurboModule:initParams in RCTTurboModuleManager
Summary:
We're going to make RCTTurboModule getTurboModule: required in D27316129. So, RCTTurboModuleManagerDelegate getTurboModule:initParams is no longer necessary.

## Changes
1. Makes TurboModuleManager stop calling RCTTurboModuleManagerDelegate getTurboModule:initParams
2. Makes getTurboModule: have the lowest priority. So, Cxx NativeModules with a getTurboModule: method won't have their getTurboModule: method executed.

Changelog: [Internal]

Reviewed By: PeteTheHeat

Differential Revision: D27316872

fbshipit-source-id: a024e55b8e3692d7117420007dd3947ecfd5019c
2021-04-08 21:15:52 -07:00
Tim Yung ebdf36c198 RN: Upgrade `AccessibilityInfo.removeEventListener` Call Sites
Summary:
Upgrades all users of `AccessibilityInfo.removeEventListener` to instead use the return value of `AccessibilityInfo.addEventListener`. This will avoid soft errors from being fired for Facebook products.

Changelog:
[Internal]

Reviewed By: kacieb

Differential Revision: D27595097

fbshipit-source-id: 7133db83c6313ae04e43fc0cc8667f562ba1af2b
2021-04-08 17:37:08 -07:00
Tim Yung e7275d5c1b RN: Reapply `AccessibilityInfo` Changes
Reviewed By: nadiia, kacieb

Differential Revision: D27595098

fbshipit-source-id: a949476c3e4681d3ddcfd1a53abe1d8f3b05c1f9
2021-04-08 17:37:08 -07:00
Araz Abishov 8207e97f91 Android: upgrading to OkHttp from v3 to v4 (#31084)
Summary:
Extends https://github.com/facebook/react-native/pull/30694 to fix tests.

OkHttp v4 was released almost a year ago. Even though v3 is still receiving security and bug fixes, most of the new improvements and features are landing in v4. This PR bumps OkHttp from v3 to v4 and addresses backward-incompatible changes.

Side effects of this upgrade:
 - OkHttp v4 depends on Kotlin's standard library, so react-native will have a transitive dependency on it.
 - The dex method count of test apk has exceeded the maximum, so multidexing had to be enabled for android tests.

## Changelog

<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->

[Android] [Changed] - Bumping OkHttp from v3 to v4.

Pull Request resolved: https://github.com/facebook/react-native/pull/31084

Test Plan: Automated (relying on the test suite) and manual testing.

Reviewed By: fkgozali

Differential Revision: D27597430

Pulled By: ShikaSD

fbshipit-source-id: 967379b41c2bcd7cfd4083f65059f5da467b8a91
2021-04-08 10:45:53 -07:00
Samuel Susla 0b8731d40d Add config flag for RuntimeScheduler
Summary:
Changelog: [internal]

Add config flags for RuntimeScheduler. Even with the flags, React will not be using it. Further changes on React side will be required.

Reviewed By: mdvacca

Differential Revision: D27616916

fbshipit-source-id: 296a040c2b6dd936dd9582e937e6db75e28f31a4
2021-04-08 10:29:07 -07:00
Joshua Gross 49b6c60bc0 EZ: fix up LayoutAnimation logs
Summary:
Make these logs more readable/useful and add debug print of ShadowView hashes in one place.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D27585135

fbshipit-source-id: 5f526856d893c32015d8b480522580732fda0cc6
2021-04-08 10:06:48 -07:00
Joshua Gross 3824c565bf ShadowView hash: add surfaceId and LayoutMetrics
Summary:
Turns out that ShadowViews that have different LayoutMetrics will have the same hash. Fix that.

This helps for debugging LayoutAnimations.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D27585133

fbshipit-source-id: f0ac50619115150339089276e34fee5ddd0270bc
2021-04-08 10:06:48 -07:00
Micha Reiser dde48fd554 Use mock clock
Summary:
Change the `TransactionTelemetryTest` to use a mock clock or change the tests to only test if at least x amount of time has passed.

Using a mock clock is the only way to make the test deterministic and be able to assert on the sub-results of the captured phases.

Changelog: [Internal] Change to the `TelemetryTest`. Neither changes the runtime behavior nor the API.

Reviewed By: sammy-SC

Differential Revision: D27618448

fbshipit-source-id: 0cbf51b050aabb75341112ea4a43bea0115082f9
2021-04-08 09:27:18 -07:00
Micha Reiser 46acfcb8fc Allow swapping the clock implementation for TransactionTelemetry
Summary:
The `TransactionalTelemetryTest`s are flaky because they use a real clock and assert on how much time has passed (with a threshold, but that's no good either).

Using the real clock in the test is the cause for the test to be flaky because it depends on the assumption that it's the sole process running, never risking to be put in the process-queue of the OS. However, that's not the case and is why the test sporadically fails if the OS decided to schedule other threads/process in the middle of the test.

This diff allows parametrising the `TransactionTelemetry` class with the clock implementation so that tests can use a Mock Clock if desired (separate diff).

Changelog: [Internal] Fabric-specific internal change.

Reviewed By: sammy-SC

Differential Revision: D27618516

fbshipit-source-id: 5a08e115b388398ca2b05b9d5ae0fd281dfe3b04
2021-04-08 09:27:18 -07:00
Samuel Susla eb13baf2a6 Introducing RuntimeScheduler module
Summary:
Changelog: [internal[

Introducing RuntimeScheduler. A coordinator of work between native and React.

Reviewed By: mdvacca

Differential Revision: D27616818

fbshipit-source-id: e90d3d9ca8907be99e61f69e62e83cece8155050
2021-04-08 04:07:34 -07:00
Ramanpreet Nara 5f0bf8b2e9 Refactor: Remove AsyncDevSupportManager.loadJSBundleFromServer
Summary:
## Rationale
- AsyncDevSupportManager.loadSplitBundleFromServer() is an override of DevSupportManager.loadSplitBundleFromServer(), which is used by the bridge. However, AsyncDevSupportManager.loadJSBundleFromServer() has no bridge analogue. This is confusing: Are the methods in AsyncDevSupportManager Venice overrides for bridge related methods? It's easy to think yes, but the answer is no.
- AsyncDevSupportManager.loadJSBundleFromServer() is an additional layer of indirection that provides very little value: all it does it create the JSBundleLoader, and call onReactContextCreated. However, it does so in 11 lines of very confusing code.

A discussion we don't have to have now: Inheritance hierarchies are very difficult to understand and de-tangle. So, instead of using inheritance to make DevSupportManager work with Venice (via AsyncDevSupportManager), should we just refactor DevSupportManager so that it can be customized to work with Venice?

Changelog: [Internal]

Reviewed By: JoshuaGross, mdvacca

Differential Revision: D27577591

fbshipit-source-id: b64dcd65e9a7c85b89443d860d441a0635547916
2021-04-07 19:37:59 -07:00