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

22484 Коммитов

Автор SHA1 Сообщение Дата
Ramanpreet Nara 7e05480cc3 Delete @synthesize turboModuleRegistry API in RCTTurboModule
Summary:
All NativeModules/TurboModules can use the following Venice-compatible API instead:
```
synthesize moduleRegistry = _moduleRegistry
```

In bridge mode, it'll look up the module via the TurboModule system/bridge.
In bridgeless mode, it'll look up the module via the TurboModule system.

Therefore, there's no need to support this API.

Changelog: [iOS][Removed] - Delete synthesize turboModuleRegistry API in RCTTurboModule

Reviewed By: fkgozali

Differential Revision: D28070740

fbshipit-source-id: d2c8285fd4c05b67fb03ce82217bf6ddfd1dd685
2021-04-28 16:49:05 -07:00
ananta 2b49664cb8 Add flow types to AccessibilityExample.js (#31384)
Summary:
[AccessibilityExample.js](https://github.com/facebook/react-native/blob/master/packages/rn-tester/js/examples/Accessibility/AccessibilityExample.js) does not have proper Flow types. Without Flow typing enforced, it is easy for bugs to be introduced when making changes to this file. This pull request enforces Flow typing in this file.

## Changelog
[General] [Fixed] - Fixed return type of `AccessibilityRoleAndStateExample`
[General] [Added] - Added Flow Types to AccessibilityExample.js

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

Test Plan:
Before:
![Screen Shot 2021-04-19 at 7 39 58 PM](https://user-images.githubusercontent.com/12180395/115248265-42c6b200-a147-11eb-8dad-058f646a1550.png)

After:
![Screen Shot 2021-04-19 at 7 40 10 PM](https://user-images.githubusercontent.com/12180395/115248284-465a3900-a147-11eb-8bff-4050ce6bd806.png)

Reviewed By: yungsters, nadiia

Differential Revision: D28004170

Pulled By: kacieb

fbshipit-source-id: 77bc44bbaf7a19c034a92a2daef302d5dc6078fa
2021-04-28 15:29:54 -07:00
Samuel Susla c3d765883a Fix frames for in text links
Summary:
Changelog: [internal]

`accessibilityFrame` needs to take scrolling position into account. To fix that, we calculate the position dynamically.

Reviewed By: mdvacca

Differential Revision: D28056789

fbshipit-source-id: 3247b3e6fd64934e99563de83d163f657828e933
2021-04-28 14:50:14 -07:00
Kacie Bawiec c68c151cda React Native sync for revisions a632f7d...2a7bb41
Summary:
This sync includes the following changes:
- **[9a2591681](https://github.com/facebook/react/commit/9a2591681 )**: Fix export //<Sebastian Markbage>//
- **[4a8deb083](https://github.com/facebook/react/commit/4a8deb083 )**: Switch the isPrimaryRender flag based on the stream config ([#21357](https://github.com/facebook/react/pull/21357)) //<Sebastian Markbåge>//
- **[bd4f056a3](https://github.com/facebook/react/commit/bd4f056a3 )**: [Fizz] Implement lazy components and nodes ([#21355](https://github.com/facebook/react/pull/21355)) //<Sebastian Markbåge>//
- **[fc33f12bd](https://github.com/facebook/react/commit/fc33f12bd )**: Remove unstable scheduler/tracing API ([#20037](https://github.com/facebook/react/pull/20037)) //<Brian Vaughn>//
- **[721238394](https://github.com/facebook/react/commit/721238394 )**: Enable strict effects mode for React Native Facebook builds ([#21354](https://github.com/facebook/react/pull/21354)) //<Brian Vaughn>//
- **[48740429b](https://github.com/facebook/react/commit/48740429b )**: Expiration: Do nothing except disable time slicing ([#21345](https://github.com/facebook/react/pull/21345)) //<Andrew Clark>//
- **[0f5ebf366](https://github.com/facebook/react/commit/0f5ebf366 )**: Delete unreferenced type ([#21343](https://github.com/facebook/react/pull/21343)) //<Andrew Clark>//
- **[9cd52b27f](https://github.com/facebook/react/commit/9cd52b27f )**: Restore context after an error happens ([#21341](https://github.com/facebook/react/pull/21341)) //<Sebastian Markbåge>//
- **[ad091759a](https://github.com/facebook/react/commit/ad091759a )**: Revert "Emit reactroot attribute on the first element we discover ([#21154](https://github.com/facebook/react/pull/21154))" ([#21340](https://github.com/facebook/react/pull/21340)) //<Sebastian Markbåge>//
- **[709f94841](https://github.com/facebook/react/commit/709f94841 )**: [Fizz] Add FB specific streaming API and build ([#21337](https://github.com/facebook/react/pull/21337)) //<Sebastian Markbåge>//
- **[e8cdce40d](https://github.com/facebook/react/commit/e8cdce40d )**: Don't flush sync at end of discreteUpdates ([#21327](https://github.com/facebook/react/pull/21327)) //<Andrew Clark>//
- **[a15586001](https://github.com/facebook/react/commit/a15586001 )**: Fix: Don't flush discrete at end of batchedUpdates ([#21229](https://github.com/facebook/react/pull/21229)) //<Andrew Clark>//
- **[89847bf6e](https://github.com/facebook/react/commit/89847bf6e )**: Continuous updates should interrupt transitions ([#21323](https://github.com/facebook/react/pull/21323)) //<Andrew Clark>//
- **[ef37d55b6](https://github.com/facebook/react/commit/ef37d55b6 )**: Use performConcurrentWorkOnRoot for "sync default" ([#21322](https://github.com/facebook/react/pull/21322)) //<Andrew Clark>//

Changelog:
[General][Changed] - React Native sync for revisions a632f7d...2a7bb41

jest_e2e[run_all_tests]

Reviewed By: JoshuaGross

Differential Revision: D28063006

fbshipit-source-id: 7e3535f80961706863b6c2188ee44b5796b2f000
2021-04-28 14:17:08 -07:00
Samuel Susla 84d55868e8 Fix DatePicker sizing issue
Summary:
Changelog: Fix possible sizing issue with DatePicker

Changing `preferredDatePickerStyle` changes size of the component without triggering re-layout of the react native screen. The fix is to make sure the size stays the same after changing the style.

Reviewed By: mdvacca

Differential Revision: D28035226

fbshipit-source-id: 2dcb50fd5ebaa0c0d01d3289c4ffa77a053cfc4a
2021-04-28 13:48:28 -07:00
Scott Kyle 2f62c2892d Fix crash in RCTCoreModulesClassProvider during quit
Summary:
This intentionally leaks the static map, since it still might be accessed after static destructors are run. This is a common approach to this problem, see https://github.com/facebook/react-native/pull/22607 and https://github.com/facebook/componentkit/pull/906 as examples. It also sets up an autorelease pool from  `RCTNativeModule::invoke` as a precaution since there's no strict guarantee one exists when it is called.

Changelog:
[iOS][Fixed] - Fix crash in RCTCoreModulesClassProvider during quit

Reviewed By: RSNara

Differential Revision: D27932062

fbshipit-source-id: fa75da4b78290027a762440ac6943c81b8594a57
2021-04-28 13:29:06 -07:00
Adam Cmiel 08ea434ba8 Migrate xplat autoglob targets (#31400)
Summary:
## Changelog: [Internal]
Pull Request resolved: https://github.com/facebook/react-native/pull/31400
Pull Request resolved: https://github.com/facebook/react-native/pull/31411

Annotate autolgob mode for apple library targets

Reviewed By: adamjernst

Differential Revision: D27890473

fbshipit-source-id: 75239c6c1871310e1ccd6576569161eb4163a3c1
2021-04-28 11:07:17 -07:00
Samuel Susla 050f84fd2b EventQueue::enqueueStateUpdate now accepts rvalue reference
Summary:
Changelog: [internal]

state infra uses rvalue references until this point. I assume the original author intended to rvalue reference even here.
This way, we avoid unnecessary copy.

Reviewed By: JoshuaGross

Differential Revision: D28057570

fbshipit-source-id: 19af480234d44acffcdbb22606607279e25c8aed
2021-04-28 11:00:03 -07:00
Samuel Susla 74d3559924 Clean up extract_uimanagerbinding_on_demand experiment
Summary:
Changelog: [internal]

Cleanup the experiment.

Reviewed By: mdvacca

Differential Revision: D27995976

fbshipit-source-id: dd6b25f5ad225243765d64b7d92b97f4423005a2
2021-04-28 04:19:24 -07:00
David Vacca a56c15894a Enable Fabric in logbox
Summary:
This diff enables  Fabric in logbox in the facebook app

changelog: [internal] internal

Reviewed By: JoshuaGross

Differential Revision: D28031255

fbshipit-source-id: 8abc301651ad09e4e48c88961bc7f3b91e6c4ae3
2021-04-27 19:45:08 -07:00
David Vacca 3d0cf8dcf8 Fix IllegalArgumentException when creating layout with negative width
Summary:
This diff fixes an IllegalArgumentException that's thrown when creating layout with negative width.

This is not a new bug, but it started firing recently (probably caused by a change in text being measured)

stacktrace:
```
stack_trace:	java.lang.IllegalArgumentException: Layout: -2 < 0
	at android.text.Layout.<init>(Layout.java:265)
	at android.text.Layout.<init>(Layout.java:241)
	at android.text.BoringLayout.<init>(BoringLayout.java:179)
	at android.text.BoringLayout.make(BoringLayout.java:61)
	at com.facebook.react.views.text.TextLayoutManager.createLayout(TextLayoutManager.java:290)
	at com.facebook.react.views.text.TextLayoutManager.measureText(TextLayoutManager.java:384) [inlined]
	at com.facebook.react.views.text.ReactTextViewManager.measure(ReactTextViewManager.java:172) [inlined]
	at com.facebook.react.fabric.mounting.MountingManager.measure(MountingManager.java:349) [inlined]
	at com.facebook.react.fabric.FabricUIManager.measure(FabricUIManager.java:461)
	at com.facebook.react.bridge.queue.NativeRunnable.run(Native Method)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
	at java.lang.Thread.run(Thread.java:923)

```

changelog: [internal] internal

Reviewed By: JoshuaGross

Differential Revision: D28015820

fbshipit-source-id: 129cd2a4c492d95d57fcdf3883b967a0b5df639a
2021-04-27 19:45:08 -07:00
David Vacca 3178e80c88 Cleanup unused variables
Summary:
EZ cleanup of unused variables in TextLayoutManager
changelog: [internal] internal

Reviewed By: JoshuaGross

Differential Revision: D28015819

fbshipit-source-id: 8e380926ebff9256e89e6cd654fa96eeb938d797
2021-04-27 19:45:08 -07:00
Ramanpreet Nara 4c5182c1cc RCTNetworking: Use RCTModuleRegistry to load handlers
Summary:
## Context
A React Native application can configure its RCTNetworking by initializing it with id<RCTURLRequestHandler> objects.

Therefore, RCTNetworking supports this initializer:
```
- (instancetype)initWithHandlersProvider:(NSArray<id<RCTURLRequestHandler>> * (^)(void))getHandlers
```

Right now, all id<RCTURLRequestHandler> are NativeModules. So, they need to be loaded using the Bridge/TurboModuleManager.

## Problem
The method [that constructs RCTNetworking](https://www.internalfb.com/code/fbsource/[6530647879a5e6d5edcfad029b39879c87e97bb3]/fbobjc/Apps/Wilde/FBReactModule2/FBReactModuleAPI/FBReactModuleAPI/FBReactModule.mm?lines=1471) is shared between bridge mode and bridgeless mode. So, the shared constructor needs to know what infra to use to load the request handlers: the TurboModuleManager, when called from a bridgeless context; the bridge, when called from a bridge context. There's no easy way to let this shared constructor know what context it's being called from. We could fork the constructor, but that's not very clean.

## Changes
In this refactor, RCTNetworking gives its _handlersProvider its RCTModuleRegistry. If the module was instantiated in bridgeless mode, RCTModuleRegistry will use the TurboModuleManager. If the module was instantiated in bridge mode, RCTModuleRegistry will use the bridge. Using RCTModuleRegistry allows the _handlersProvider to load id<RCTURLRequestHandler> from correct infra, in both contexts.

Changelog: [iOS][Changed] - Give RCTNetworking handler provider block RCTModuleRegistry

Reviewed By: PeteTheHeat

Differential Revision: D28013000

fbshipit-source-id: 956d660771ab18f5e7f24fcc28792f9a217146e7
2021-04-27 15:03:05 -07:00
Ramanpreet Nara af6bcfa3ab RCTImageLoader: Use RCTModuleRegistry to load loaders/decoders
Summary:
## Context
A React Native application can configure its RCTImageLoader by initializing it with two different sets of objects:
- id<RCTImageURLLoader>
- id<RCTImageDataDecoder>

Therefore, RCTImageLoader supports this initializer:
```
- (instancetype)initWithRedirectDelegate:(id<RCTImageRedirectProtocol>)redirectDelegate
                         loadersProvider:(NSArray<id<RCTImageURLLoader>> * (^)(void))getLoaders
                        decodersProvider:(NSArray<id<RCTImageDataDecoder>> * (^)(void))getHandlers
```

Right now, both the id<RCTImageURLLoader>s and id<RCTImageDataDecoder>s are NativeModules. So, they need to be loaded using the Bridge/TurboModuleManager.

## Problem
The method [that constructs RCTImageLoader](https://www.internalfb.com/code/fbsource/[6530647879a5e6d5edcfad029b39879c87e97bb3]/fbobjc/Apps/Wilde/FBReactModule2/FBReactModuleAPI/FBReactModuleAPI/FBReactModule.mm?lines=1462-1469) is shared between bridge mode and bridgeless mode. So, the shared constructor needs to know what infra to use to load the loaders/decoders: the TurboModuleManager, when called from a bridgeless context; the bridge, when called from a bridge context. There's no easy way to let this shared constructor know what context it's being called from. We could fork the constructor, but that's not very clean.

## Changes
In this refactor, RCTImageLoader gives its loadersProvider and decodersProvider its RCTModuleRegistry. If the module was instantiated in bridgeless mode, RCTModuleRegistry will use the TurboModuleManager. If the module was instantiated in bridge mode, RCTModuleRegistry will use the bridge. Using RCTModuleRegistry allows these two blocks to load the RCTImageURLLoaders and RCTImageDataDecoder from correct infra, in both contexts.

Changelog: [iOS][Changed] - Give RCTImageURLLoader's loader/decoder provider blocks RCTModuleRegistry

Reviewed By: PeteTheHeat

Differential Revision: D28012999

fbshipit-source-id: 09c787923b57bbf72aff95b504f88ee1f2f44283
2021-04-27 15:03:05 -07:00
Micha Reiser d6cd2e6559 Upgrade to Jest 26.6.3
Summary: Changelog: [Internal]

Reviewed By: motiz88

Differential Revision: D27996469

fbshipit-source-id: 41f11be8477f5c1314e87f365d09a0c03f272284
2021-04-27 09:42:13 -07:00
Joshua Gross 119e8f4cd8 Differ: in flattening/unflattening nested case, reduce code duplication
Summary:
Refactor a code block that is duplicated 2x. Logic stays the same besides renaming, and a ternary operator to decide between getting the children from "old" or "new" tree.

Tests can help us refactor knowing that the logic is still correct.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D28018994

fbshipit-source-id: d34a033444e67091e44ff6a747fd39846c165238
2021-04-27 09:38:43 -07:00
Joshua Gross 1e68a5f573 Differ: simplify nested flattening/unflattening code
Summary:
There's a case here where we do a loop, with a map loopup, and nested map lookup inside of that. It's not particularly efficient and was done because we have multiple distinct pointers to distinct ShadowViews that are backed by the same ShadowNode. Now due to previous, recent refactoring, we can simplify this case a lot.

The code WAS correct before, just confusing and not particularly efficient. Tests can prove that this is still correct.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D28018996

fbshipit-source-id: a7c8148802650c88888960c9c099954e0f8bc357
2021-04-27 09:38:43 -07:00
Joshua Gross 121a84496c Differ: remove incorrect comment
Summary:
This is no longer true because of the "scope" mechanism.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D28018995

fbshipit-source-id: 91470234bb15f7feeb92b41613b0bbdbe42ccb27
2021-04-27 09:38:43 -07:00
Joshua Gross 7131791ab1 Differ: dedupe more code in main differ loop
Summary:
I am deduping a duplicated block, and adding comments to explain when we create INSERT/REMOVE mutations immediately and when we defer creation.

Theoretically the ordering of mutations will be more consistent now, which ~shouldn't matter, but is probably a decent property to have. In particular, before, in some cases
both of these orderings were possible in various scenarios:

```
INSERT X -> Y
INSERT Y -> Z
```

and

```
INSERT Y -> Z
INSERT X -> Y
```

Both of those are fine/correct/won't cause issues on any known platforms. But now, at least for the two cases touched here, only this ordering will be produced:

```
INSERT Y -> Z
INSERT X -> Y
```

meaning we build the tree from the bottom-up (the "bottom" being the root) and do out-of-order inserts less frequently.

Again, the biggest part of this diff should be readability/refactoring/de-duplicating logic, but more consistent orderings is a nice-to-have.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D28017926

fbshipit-source-id: 5941588d0c8bba8b0df7d0084d5d198f4b7c2427
2021-04-27 09:38:43 -07:00
Andrei Shikov 0aa7e5b5d4 Back out "Assign batch number to only batched animated instructions"
Summary:
This change broke some animations on non-Fabric surfaces due to inconsistent batching of animation operations.

Changelog: [Internal]

Reviewed By: JoshuaGross

Differential Revision: D28013968

fbshipit-source-id: 2f65c799dbe00168f1e756ef0af60206df5a8fcc
2021-04-27 04:00:16 -07:00
Andrei Shikov ef0db95300 Back out "Adjust animation batch numbers to be consistent when controlled by native"
Summary:
This change caused crashes in animations on some surfaces.

Changelog: [Internal]

Reviewed By: JoshuaGross

Differential Revision: D28013969

fbshipit-source-id: 95845c69d6e67d59582ea14ad08cbf42fd3e2f8f
2021-04-27 04:00:16 -07:00
Samuel Susla 841756b150 Implement RuntimeScheduler::getCurrentPriorityLevel
Summary:
Changelog: [internal]

Implement `RuntimeScheduler::getCurrentPriorityLevel`.

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

Reviewed By: ShikaSD

Differential Revision: D27998510

fbshipit-source-id: 634c09185f9eae8f7afcdb6acd9b74effd587da7
2021-04-27 00:29:04 -07:00
Nadiia D 46ffe84453 Make RootTag an opaque type
Summary:
Changelog:
[General][Changed] Make the RootTag an opaque type

Reviewed By: yungsters

Differential Revision: D27992320

fbshipit-source-id: 2901f0e59f573106295b986fe04db227134235da
2021-04-26 22:57:55 -07:00
Nadiia D 9b98edcd01 Stabilize RootTagContext
Summary:
Changelog:
[General][Removed] - Stabilize RootTagContext

Reviewed By: TheSavior

Differential Revision: D27954168

fbshipit-source-id: ff04375f00229b1a601cbd1182001885d8b687ec
2021-04-26 22:57:55 -07:00
Nadiia D 9d489354ae Stabilize RootTagContext
Summary:
Changelog:
[General][Added] - Stabilize RootTagContext. And temporarily export both `unstable_RootTagContext` and `RootTagContext`

Reviewed By: TheSavior

Differential Revision: D27951427

fbshipit-source-id: dff8d4ca07c89edeeb517a42a3922e4e23899d8e
2021-04-26 22:57:55 -07:00
Tim Yung 8719a2e9a9 msggen: Upgrade `jest` Dependency
Summary:
Upgrades `jest` to mitigate a dependency with security vulnerabilities.

Changelog:
[Internal]

Reviewed By: mhorowitz

Differential Revision: D28009549

fbshipit-source-id: ea3313a452e9e4b79d68781ffc37c26b00f26da5
2021-04-26 15:15:46 -07:00
Tim Yung 6ea72fa231 msggen: Fix Missing `RefProperty.recursive`
Summary:
This was missing, causing the test to fail.

Changelog:
[Internal]

Reviewed By: mhorowitz

Differential Revision: D28009429

fbshipit-source-id: 51d4366b4feb6a2300c5bd05007dd9455bdcd77b
2021-04-26 15:15:45 -07:00
Kacie Bawiec 0afd71a18d Convert require to import in Libraries/Components
Summary:
Changelog:
[General][Changed] Convert require statements to use import from in Libraries/Components

Reviewed By: lunaleaps

Differential Revision: D27921557

fbshipit-source-id: 3f1618455a47a56c4a090f3ececfef88476c0b8a
2021-04-26 12:50:59 -07:00
Joshua Gross ca3aae7980 Differ: fix unit test case 1167342011
Summary:
Unit test case seed 1167342011 encodes a case where the differ produces a DELETE and CREATE of the same node in the same frame, which we consider an error.

It turns out this was caused by nested "unflatten" operations and this bit of deleted code specifically. We were deleting an unmatched node from a parent call's dictionary of nodes,
which prevented it from being matched in the "old" tree later on.

This is only possible now that we attach pointers to the "other" ViewNodePair when they're matched, so we can check existence of that pointer instead of inclusion in dictionaries to decide if we need to DELETE/CREATE a node and its subtree.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D28003330

fbshipit-source-id: 305440ef20b921883c1d6e38a4a4072e5a7f95ac
2021-04-26 11:59:11 -07:00
Joshua Gross 4bc81422ed Differ: fix debug log compilation
Summary:
Only compiles when debug flags are added locally. This fixes compiler errors.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D28003331

fbshipit-source-id: 0383f41bbb405a1b089f155d2a7f3398795ac965
2021-04-26 11:59:11 -07:00
Joshua Gross 2c62e02b2b Differ: comments
Summary:
Just adding a comment for future possible refactoring here.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D28003338

fbshipit-source-id: ec307314d18d69f8c77c2b2afff1f3953ca55473
2021-04-26 11:59:11 -07:00
Joshua Gross 1b83922cb6 Differ: delete impossible and redundant blocks
Summary:
These blocks either are not necessary due to other mechanisms, or are impossible to hit.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D28003336

fbshipit-source-id: f2321073de77c0f0173a9a0891be2a3012578b01
2021-04-26 11:59:11 -07:00
Joshua Gross 08a1531a1f Differ: simplify flatten/unflatten logic
Summary:
Since each ShadowViewNodePair will point to any matched pair in the "other" tree during diffing, we can rely on the presence of the "other" pointer instead of
always removing nodes from `deletionCreationCandidatePairs` when they're matched.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D28003335

fbshipit-source-id: 0b886946eedc497091ca79c436f160b3d4bf3f1e
2021-04-26 11:59:11 -07:00
Joshua Gross 6e13040ecb Differ: consolidate two code paths into updateMatchedPairSubtrees
Summary:
There's a lot of code duplication in the differ. Reduce by factoring a duplicated code path into `updateMatchedPairSubtrees`.

This handles cases of updating trees with flattening or unflattening.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D28003339

fbshipit-source-id: cbbf890ba447b29d79aedea374b173de40e71334
2021-04-26 11:59:11 -07:00
Joshua Gross 11e166b9aa Differ: refactor: use mutation container list to store all temporary mutations
Summary:
Simple refactor to use this struct to store lists instead of references to lists.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D28003337

fbshipit-source-id: a37fa23ed3c1e1b273f92bf5ad5179a0fd1d852b
2021-04-26 11:59:10 -07:00
Joshua Gross 3a99c7cdbb Differ: add failing test case 1167342011 which covers an existing error
Summary:
Found by running random tests and extracting a failing seed.

This error existed in master (and existed prior to recent refactors) and will be fixed by the end of this stack.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D28003332

fbshipit-source-id: 9c4a10d236c24337b089c44e8c1beb22358cfb05
2021-04-26 11:59:10 -07:00
Joshua Gross 1b4a5176d7 Testing mechanism to find new failing Differ test-cases
Summary:
This code can be uncommented locally and run several times to discover new failing seeds.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D28003333

fbshipit-source-id: 6a3b6c08ae02bccc5c4d26067409ff6c736f8a89
2021-04-26 11:59:10 -07:00
Joshua Gross 66ba89921a Differ tests: use react_native_assert(false) instead of FAIL() to get logs upon test failure
Summary:
Calling `FAIL()` doesn't flush glog, but `react_native_assert(false)` does. Both will have the effect of failing the test.

Changelog: [Internal]

Reviewed By: sammy-SC

Differential Revision: D28003334

fbshipit-source-id: 802ad1f59e46eb048fd6ca95f5978eeaaad83f3a
2021-04-26 11:59:10 -07:00
Samuel Susla 9cd98fa3ee Prevent redundant dispatches onto RuntimeExecutor queue in AsynchronousEventBeat::induce
Summary:
Changelog: [internal]

Prevent redundant calls to RuntimeExecutor by making sure no two calls to the executor are scheduled at the same time.

Reviewed By: mdvacca

Differential Revision: D27989412

fbshipit-source-id: 8f9b1591f7c9c2265fd4b05bf3dc5505ffc2568b
2021-04-25 16:15:25 -07:00
Tim Yung f598dd0ee3 RN: Create Experiment for `collapsable` (iOS)
Summary:
Sets up an experiment that enables `collapsable` in Fabric for iOS. This will enable us to validate with production data that enabling the use of this prop does not cause unexpected regressions.

Changelog:
[internal]

Reviewed By: mdvacca

Differential Revision: D27987619

fbshipit-source-id: 9b1c0ff45bed09b1e72ad7d9c782f07bb4211cc6
2021-04-25 01:17:55 -07:00
Tim Yung b914153286 Animated: Delete `getNode()` on Refs
Summary:
In 0.62, `createAnimatedComponent` was changed to use `forwardRef` instead of requiring callers to use `ref.getNode()`. In order to preserve backward-compatibility, `ref.getNode()` was monkey-patched onto the returned ref, if possible, to return the `ref` and output a console warning.

Three major (well, technically, minor) releases later, we are dropping support for `getNode()`. Calling it on the `ref` of an animated component will begin to fail after this (unless the underlying component itself actually implements a `getNode()` method on its imperative handle).

Changelog:
[General][Removed] - Removed `getNode()` from animated component refs.

Reviewed By: nadiia

Differential Revision: D27979882

fbshipit-source-id: 885c3dbf4f2749c994fc2662dd6f16ff3dd887c7
2021-04-24 17:09:12 -07:00
Samuel Susla 1b592631a7 Prevent redundant dispatches onto RuntimeExecutor queue in AsynchronousEventBeat::induce
Summary:
Changelog: [internal]

Current implementation of `AsynchronousEventBeat` dispatches lambdas through `RuntimeExecutor` regardless if it has done so previously.

So if `AsynchronousEventBeat::induce` is called 30 times, it will dispatch 30 lambdas.

In `AsynchronousEventBeatV2`, we make sure only single lambda is dispatched to `RuntimeExecutor` at a time.

Reviewed By: mdvacca

Differential Revision: D27940300

fbshipit-source-id: 2bad25c86315c1712b4a1da8c1d4702734cec70f
2021-04-24 03:21:09 -07:00
Samuel Susla 09cb12c26c Pass eventPriority by value instead of reference
Summary:
Changelog: [internal]

EventPriority is backed by int, passing it by reference doesn't provide any performance benefits. Quite contrary, it can make it slower because of indirectness (in our case it is probably negligible).

Reviewed By: mdvacca

Differential Revision: D27938600

fbshipit-source-id: 37d1312627dd5a8f9012dfb35d21afe716a16ad7
2021-04-24 03:21:08 -07:00
Kevin Gozali f31497354b iOS: make RCTSurfaceHostingView have default backgroundColor
Summary:
Previously it defaults to using transparent color (iOS default), but when using `RCTSurfaceHostingProxyRootView` we actually manually set to `[UIColor whiteColor]`. However, if the surface is initialized via a different API, the color wasn't set. To avoid confusion and backward incompatibility, let's just set the same background color here.

We can decide in the future if the default color should be transparent instead.

Changelog: [Fixed][iOS] RCTSurfaceHostingView default background color is now consistent with RCTRootView

Reviewed By: RSNara

Differential Revision: D27973748

fbshipit-source-id: c506afbc5629df6647277aa2323f084773c8e760
2021-04-23 19:54:54 -07:00
Ramanpreet Nara d48c2be46f Wire up RuntimeExecutorFlushing to MobileConfig
Summary:
With D27975839, RuntimeExecutor will be able to start flushing the queued up NativeModule calls in every call from C++ -> JavaScript. We're going to test this feature to measure its impact. In this diff, I wire up the the MobileConfig to ReactFeatureFlags.

Changelog: [Internal]

Reviewed By: JoshuaGross

Differential Revision: D27978112

fbshipit-source-id: 47e1e74398c62755bb0fdc6b54b7fd3aa47eb877
2021-04-23 18:16:03 -07:00
Ramanpreet Nara c0ec82e61e Add flushing to RuntimeExecutor
Summary:
## Motivation
With the bridge, every call into JS flushes the queue of NativeModule calls. Fabric bypasses this mechanism, because it uses a RuntimeExecutor that schedules work directly on the JavaScript thread. This diff makes Fabric's RuntimeExecutor also flush the queue of NativeModule calls.

This likely won't fix anything in Fabric, because we don't execute any async NativeModule calls on Fb4a. However, this is necessary for the drainMicrotask work we're doing in D27729702 (7310847758), because (1) we need to drain the Hermes microtask queue on every call from C++ -> JavaScript (2) we drain the microtask queue [inside JSIExecutor::flush()](de477a0df6/ReactCommon/jsiexecutor/jsireact/JSIExecutor.cpp (L427),L445).

Changelog: [Android][Fixed] - Flush JSIExecutor in Fabric's RuntimeExecutor

Reviewed By: JoshuaGross

Differential Revision: D27975839

fbshipit-source-id: 27f031fb36593253da116a033e30998475eb1473
2021-04-23 18:16:03 -07:00
Ramanpreet Nara db3625a3b0 Refactor: Move RuntimeExecutor into Instance.cpp
Summary:
RuntimeExecutor is currently declared inside NativeToJsBridge. It doesn't need to be: Instance.cpp can use NativeToJsBridge::runOnExecutorQueue to schedule work on the JS Thread. So, this diff moves RuntimeExecutor out of NativeToJsBridge into Instance.cpp. Now, both the JS CallInvoker and the RuntimeExecutor are declared in the same file.

Changelog: [Internal]

Reviewed By: JoshuaGross

Differential Revision: D27975840

fbshipit-source-id: aa06f479fa24bb7a15bfd21712df5414a183266c
2021-04-23 18:16:03 -07:00
Neil Dhar c68c55469f Initialise LineMeasurement::xHeight in constructor
Summary:
Fix a bug in the constructor of `LineMeasurement` where it did not initialise `xHeight` correctly.

Changelog: [Internal]

Reviewed By: JoshuaGross

Differential Revision: D27972942

fbshipit-source-id: a56d55fdfe286bd11a6a81a3d024504f070bdb19
2021-04-23 17:46:38 -07:00
Ramanpreet Nara da150343f7 TM Create: log error when method queue is nil
Summary:
When TurboModuleManager creates TurboModules, it creates and assigns a method queue to the module using ObjC's Associated Object API:

https://www.internalfb.com/code/fbsource/[c91dc16f4b63]/xplat/js/react-native-github/ReactCommon/react/nativemodule/core/platform/ios/RCTTurboModuleManager.mm?lines=636

Down the line, we retrieve this method queue, and use it to create a native CallInvoker:

https://www.internalfb.com/code/fbsource/[c91dc16f4b63abd05c7c9a038e88ca692a453c69]/xplat/js/react-native-github/ReactCommon/react/nativemodule/core/platform/ios/RCTTurboModuleManager.mm?lines=279-284

We should assert that this method queue isn't nil.

Changelog: [Internal]

Reviewed By: mdvacca

Differential Revision: D27956219

fbshipit-source-id: 2554cf2bffc732bb895e6dc082338a38b05f6580
2021-04-23 15:59:24 -07:00
Ramanpreet Nara 497eb578ab Fix invalidation for modules with infra-generated method queues
Summary:
When invalidating TurboModules, the TurboModule infra looks for a methodQueue method on the TurboModule (line 871 below). If it finds one, the TurboModuleManager dispatches module invalidate on that method queue:

https://www.internalfb.com/code/fbsource/[c91dc16f4b63abd05c7c9a038e88ca692a453c69]/xplat/js/react-native-github/ReactCommon/react/nativemodule/core/platform/ios/RCTTurboModuleManager.mm?lines=847-848%2C870-883

## The Problem

TurboModules that neither provide a method queue, nor request a method queue won't respond to selector(methodQueue). For those modules, the TurboModule system won't dispatch invalidate to their method queue

## The Fix
Calling selector(methodQueue) is an unreliable way of getting the module's method queue. The TurboModuleManager attaches a method queue to every TurboModule as an associated object:

https://www.internalfb.com/code/fbsource/[c91dc16f4b63]/xplat/js/react-native-github/ReactCommon/react/nativemodule/core/platform/ios/RCTTurboModuleManager.mm?lines=636

In this diff, in the TurboModule invalidate method, we retrieve the method queue using ObjC's associated object API. This guarantees that all TurboModules will be invalidated on their method queues.

Changelog: [iOS][Fixed] - Invalidate TurboModules with infra-generated method queues on their method queues

Reviewed By: appden

Differential Revision: D27954644

fbshipit-source-id: af4408e444d03a15d8d8e154b3980511b81d5fb1
2021-04-23 15:59:24 -07:00