Skip to content

[pull] master from facebook:master#68

Merged
pull[bot] merged 11 commits intochanhong:masterfrom
facebook:master
Apr 12, 2021
Merged

[pull] master from facebook:master#68
pull[bot] merged 11 commits intochanhong:masterfrom
facebook:master

Conversation

@pull
Copy link
Copy Markdown

@pull pull bot commented Apr 12, 2021

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

Andrei Shikov and others added 11 commits April 12, 2021 09:18
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
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
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
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
Summary:
Cleans up some minor redundant internal types in `_EventEmitter.js`.

Changelog:
[Internal]

Reviewed By: rubennorte

Differential Revision: D27712301

fbshipit-source-id: e6affcb7948e0f47a1775b74b12f59ec2a6abddb
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
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
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
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
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
Summary:
fix #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: #30685

Test Plan:
1. Create an empty app with react-native 0.63.4, copy&paste the App.js from issue #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
@pull pull bot added the ⤵️ pull label Apr 12, 2021
@pull pull bot merged commit 1b06835 into chanhong:master Apr 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants