Summary:
Minor changes to the `Animated` examples index module to make the static typing a bit more intuitive.
Changelog:
[Internal]
Reviewed By: kacieb
Differential Revision: D28799742
fbshipit-source-id: f798631081538e79fc58377105db4e47b9728843
Summary:
Minor reorganization of `AnimatedGratuitousApp` to be a separate top-level directory in `examples/`, like `Animated`.
Changelog:
[Internal]
Reviewed By: kacieb
Differential Revision: D28799737
fbshipit-source-id: b0329e420d6eae912e91d0d74b68ac299c9bd9f3
Summary:
Creates an experimental stub implementation of `createAnimatedComponent` to be implemented in future commits.
Changelog:
[Internal]
Reviewed By: lunaleaps, kacieb
Differential Revision: D28799738
fbshipit-source-id: dc3fbee557db353de6807bd87561f8f372d7cab5
Summary:
Sets up an injection mechanism for experimenting in production with an alternate implementation of `createAnimatedComponent`.
This will be used to implement and refine a new `createAnimatedComponent` that is compatible with concurrent rendering.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D28799739
fbshipit-source-id: 46ba2dd6137f7bf73ce8a659698533ed3985516f
Summary:
While it is possible in the React Native implementation for Android to provide a custom configuration for HTTP requests, the iOS implementation does not allow for the same customization. As the NSURLSession used for HTTP requests on iOS is configured internally, one may for instance not supply an ephemeral configuration for HTTP requests. Other concerns related to the given problem have been addressed in the community: https://github.com/react-native-community/discussions-and-proposals/issues/166. I did make a PR with an RFC in the community repo, but after some discussion in the said repo, I figured I might as well make a PR with a suggestion :)
## Changelog
[iOS] [Added] - Allow for configuring the NSURLSessionConfiguration
Implement a C function `RCTSetCustomNSURLSessionConfigurationProvider` which gives the app programmer the ability to provide a block which provides an NSURLSessionConfiguration that will be used for all HTTP requests instead of the default configuration. The provided block will be called when the session configuration is needed.
Pull Request resolved: https://github.com/facebook/react-native/pull/27701
Test Plan: Unsure if this can be tested in any other way than uncommenting the example code in `RNTester/RNTester/AppDelegate.mm`.
Reviewed By: yungsters
Differential Revision: D28680384
Pulled By: JoshuaGross
fbshipit-source-id: ae24399955581a1cc9f4202f0f6f497bfe067a5c
Summary:
Bumped react-native-community/cli to v6 to update metro to 0.66 to fix fast-refresh issues
Also updated the manual test e2e script for easier testing. (using npm install would create a package-lock.json and conflict with yarn.lock)
## 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
-->
[GENERAL] [UPDATE] - updated react-native-community/cli to v6 (hence updating metro to 0.66)
Pull Request resolved: https://github.com/facebook/react-native/pull/31597
Test Plan: I've tested fast-refresh works with / without hermes
Reviewed By: TheSavior
Differential Revision: D28852660
Pulled By: yungsters
fbshipit-source-id: af338e4dd1d52c62949d71f42773963d89bca9db
Summary:
The RuntimeExecutor that Fabric gets from the bridge doesn't call JSIExecutor::flush(). In the legacy NativeModule system, we're supposed to flush the queue of NativeModule calls after every call into JavaScript. The lack of this flushing means that we execute NativeModule calls less frequently with Fabric enabled, and TurboModules disabled. It also means that [the microtask checkpoints we placed inside JSIExecutor::flush()](https://www.internalfb.com/code/fbsource/[62f69606ae81530f7d6f0cba8466ac604934c901]/xplat/js/react-native-github/ReactCommon/jsiexecutor/jsireact/JSIExecutor.cpp?lines=427%2C445) won't be executed as frequently, with Fabric enabled.
Changelog: [Android][Fixed] - Flush NativeModule calls with Fabric on Android, on every Native -> JS call.
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D28620982
fbshipit-source-id: ae4d1c16c62b6d4a5089e63104ad97f4ed44c440
Summary:
Since moving Switch to a function component it is no longer possible to get the native switch ref. This adds forwardRef so it is possible again.
## Changelog
[General] [Fixed] - Fix Switch ref forwarding
Pull Request resolved: https://github.com/facebook/react-native/pull/31629
Test Plan: Tested the change in an app using react-native-gesture-handler, which tries to set a ref on Switch. Also made sure flow still passes.
Reviewed By: TheSavior
Differential Revision: D28839605
Pulled By: lunaleaps
fbshipit-source-id: 1fee86145caeabb60c0010bb9062dddca419f7ca
Summary:
Virtual views that are flattened and don't "FormsView" on-screen should not be preallocated.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28811419
fbshipit-source-id: 949dcbf4cf3791355c58af785603b35fa50f3f02
Summary:
This hack should not be necessary. It should be fixed at Differ or LayoutAnimations level if there are existing issues there.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28810021
fbshipit-source-id: 98b8d2ae9991ad527a3b3e90943d75063b2a4496
Summary:
jcenter is read-only now, and newer versions of dependencies will be published to either MavenCentral or Jitpack. This PR removes jcenter to avoid future issues, then uses MavenCentral and Jitpack as replacement. Current flipper depends on Stetho version that is not available on MavenCentral, so had to exclude and bump the version.
Both Gradle and Buck successfully download all the dependencies.
## Changelog
[Android] [Changed] - Remove jcenter
Pull Request resolved: https://github.com/facebook/react-native/pull/31609
Test Plan: rn-tester builds and runs as expected.
Reviewed By: mdvacca
Differential Revision: D28802444
Pulled By: ShikaSD
fbshipit-source-id: 043ef079d0cda77a1f8dd732678452ed712741a4
Summary:
As suggested by motiz88 on D28421692 (https://github.com/facebook/react-native/commit/883e0d5752b952c829c8d45504d3532f52bb272f), make sure to still report fatal "warnings".
Changelog:
[General][Fixed] Report fatal errors even if its `type` is "warn".
Reviewed By: motiz88
Differential Revision: D28815228
fbshipit-source-id: 8d3b77958ef687a4ce64bdfccbf6ce2dc5557eaf
Summary:
API of Jest transformers is changing in Jest 27. The new version of `jest/create-cache-key-function` handles both current versions of the API and the upcoming 27 API.
Ref: https://github.com/facebook/jest/pull/10834
## 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
-->
[Internal] [Changed] - Use version of `jest/create-cache-key-function` compatible with upcoming Jest v27 release
Pull Request resolved: https://github.com/facebook/react-native/pull/30637
Test Plan: I've tested locally that it works with both a `jest@latest` and `jest@next` release.
Reviewed By: yungsters
Differential Revision: D28807361
Pulled By: hramos
fbshipit-source-id: 9d9ccb4d7f91b30bcbf3d28202bb74ce7499a91b
Summary:
Creates a new RNTester example to verify facebook/react-native#31538 (D28631465).
Changelog:
[Android][Added] - RNTester example for adjusting text with dynamic layout.
Reviewed By: kacieb
Differential Revision: D28779870
fbshipit-source-id: 5297a823645d1e9e35d4c86b491f3c225ecc9543
Summary:
EventEmitter is not transmitted from C++ to Java until an UPDATE operation is enqueued. Practically this usually happens "right away", but in the case of an Image component, especially, the EventEmitter could be missing while events are being fired from the native side (for example, loading events).
The fix is just to pass EventEmitter in sooner, in both Create and Preallocate. There should be no ill effect since EventEmitter is nullable anyway.
One potential side-effect: since Views can be PreAllocated and potentially never deallocated until StopSurface is called, this could result in more EventEmitter objects being leaked and retained from Java. I believe the fix is to remove PreAllocated Views more aggressively.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28810022
fbshipit-source-id: ae4c8b4eefe619d9a99fa5f90f612d6dd4880da5
Summary:
Bump Gradle to 6.9 which supports Apple Silicon, also Android Gradle Plugin 4.2.1 which defaults to Java 1.8 so no additional config required.
## Changelog
[Android] [Changed] - Bump Gradle to 6.9, Android Gradle Plugin to 4.2.1
Pull Request resolved: https://github.com/facebook/react-native/pull/31593
Test Plan: rn-tester builds and runs as expected
Reviewed By: mdvacca
Differential Revision: D28711942
Pulled By: ShikaSD
fbshipit-source-id: 2a4616cd0f17db7616ab29dea1652717f2cd0f6d
Summary:
This pre-suppresses the 153 error diff ahead of its release, since it is large.
Changelog: [Internal]
Reviewed By: mroch
Differential Revision: D28754374
fbshipit-source-id: 1806f53bc7d804644d434583a2dcd6da63d00328
Summary:
Removes stale feature flag that was in production for a couple of months. Fix helped to decrease number of crashes significantly, so we can remove it.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28757995
fbshipit-source-id: 375da09c11f265e8bbe03cd99de1b83f168420ce
Summary:
Touch event logic has been recently modified to contain surfaceId only in the new renderer. This change aligns OSS tests that have been failing for them.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28749961
fbshipit-source-id: 483ab3ac97bbdc4f1fbdb2a8c699ef060cca9f77
Summary:
Adds logs to indicate that MountItem was queued instead of executed.
Also moves logging of preMount items to dispatcher for consistent logging with other items.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28690203
fbshipit-source-id: 14d24f0bebb97a810127f5187b4d46f66b6c836f
Summary:
Add more detail about requesting review in the contribution guide.
In the GAAD initiative it's particularly useful to know when certain PRs need our attention so wanted to highlight the code review process to remind contributors to request reviewers.
## Changelog
[General] [Added] - Added more detail about the review process
Pull Request resolved: https://github.com/facebook/react-native/pull/31590
Test Plan: Grammar, clarity review
Reviewed By: TheSavior
Differential Revision: D28719869
Pulled By: lunaleaps
fbshipit-source-id: 9213fefbe602588f9e5cee7ba240b93bc7f291b5
Summary:
Changelog: [internal]
There is a possibility of race between updating scrollview's state and virtualised list asking for layout of individual cells.
To make sure the race doesn't happen, state must be updated before dispatching onScroll event.
Android has implemented a different mechanism to tackle this issue in D28558380 (https://github.com/facebook/react-native/commit/b161241db2ef74d2e4bff36d4972f5f0312dcc44).
Reviewed By: JoshuaGross
Differential Revision: D28642737
fbshipit-source-id: 33874beac69fc5a66eeb7f459fd89cd0b00dafcf
Summary:
Changelog: [internal]
collapsable was not passed to Fabric because view configs are built using Paper' ViewManagers.
Reviewed By: p-sun
Differential Revision: D27944688
fbshipit-source-id: 73a5646e25b3dd7a1a9dfc1079406047ab483d88
Summary:
Changelog: [internal]
Use getter function instead of accessing ivar. This makes for clearer APIs.
React part is implemented in https://github.com/facebook/react/pull/21553
Reviewed By: JoshuaGross
Differential Revision: D28675372
fbshipit-source-id: cf99f8482067bfc0fd57d39fda9656abd665bb69
Summary:
Replaces deprecated `translateX` and `translateY` props with `transform` prop in PanResponderExample. This fixes the RNTester example for react-native-windows, which doesn't support the deprecated props.
Changelog:
[General][Fixed] - [RNTester] Use transform prop in PanResponderExample
Reviewed By: kacieb
Differential Revision: D28676164
fbshipit-source-id: 437912b5abf6ca74f0043ded7a902a5938bcf93a
Summary:
Changelog: [internal]
Introduces synchronous access to the runtime from RuntimeScheduler.
At the moment, this is not used anywhere.
In case RuntimeScheduler isn't defined (controlled by MC), falls back to RuntimeExecutor.
Reviewed By: mdvacca
Differential Revision: D28024380
fbshipit-source-id: 90be36dd390202540ed51940a4396040f043cd90
Summary:
Changelog: [internal]
This is a mechanism that will guess event's React priority based on other events ongoing on the platform.
If an event happens within span of ContinuousStart -> ContinuousEnd and its category is unspecified, we deduce it's React priority to be default. All other events are discrete.
Special case: `onScroll`, which is always treated as "Default".
Reviewed By: JoshuaGross
Differential Revision: D28485060
fbshipit-source-id: d2eae63dbcf03271dfed97128a1590dd165a3ce2
Summary:
Changelog: [internal]
Pulling out event queue processing to its separate class. We will be adding more logic there so it makes sense to separate it for simplicity and testability purposes.
Alternative names that came to mind: `EventsProcessor`, `EventsDispatcher`.
Reviewed By: JoshuaGross
Differential Revision: D28572283
fbshipit-source-id: 1cb2459f616b9995f66da80d50c401e68002da7f
Summary:
TL;DR: simplify and delete a bunch of stuff that shouldn't be necessary in Fabric.
I discovered that this event dispatcher (and the older one this is based on) is triple-queueing: we queue events into "staging", and then post "dispatch events" to only run /on the JS thread/. Even in Fabric. Then, each of these events is emitted into C++ where they are queued /again/! This refactor eliminates one more level of queueing - instead of scheduling dispatch for the JS thread, we just emit them directly to C++ when they're received in Java.
Unfortunately, the EventDispatcher is also used to drive AsyncEventBeat in C++:
1. EventBeatManager.onBatchEventDispatched: https://fburl.com/diffusion/qf6dyhsw
In the C++ impl, it indirectly will drive the AsyncEventBeat/AsyncEventBeatV2.
2. onBatchEventDispatched is ONLY called from EventDispatcherImpl: https://fburl.com/codesearch/mxk8ifyj
3. Which is queued and only runs on the JS thread: https://fburl.com/codesearch/czvbst4u
This means the AsyncEventBeat is only ticked when the JS thread is free, and ticks will be skipped when the JS thread is occupied for long periods.
Now, in this refactor, when this class is used it will drive AsyncEventBeat on every UI tick. This is also potentially not correct. On iOS (Fabric), AsyncEventBeat is driven when the UI thread is "about to sleep".
For now I'm not going to worry about that detail - it is significant, but Fabric+Android is currently /not doing the right thing/ and it's not clear that we want to maintain iOS behavior. This is something we need to discuss further and figure out.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28654033
fbshipit-source-id: b3cb9b706343c8dd3c4cf84f24388908c57e2138
Summary:
Upgrade jsc-android to latest stable version. Hopefully this should finally fix https://github.com/facebook/react-native/issues/25494.
Before Hermes totally replaced JSC, it should be worth to have this and make JSC stable
## Changelog
[Android] [Changed] - Upgrade jsc-android to 250230.2.1
Pull Request resolved: https://github.com/facebook/react-native/pull/31304
Test Plan: Launch app with new jsc-android and see everything works fine.
Reviewed By: TheSavior
Differential Revision: D28630503
Pulled By: yungsters
fbshipit-source-id: 84510f91c81d4aaefe265d5492677ad6ff10e0fe
Summary:
JS side expects the property name to be "actionName", and this change updates it to that.
Changelog:
[iOS][Fixed] - Use actionName in accessibility event callback
Reviewed By: JoshuaGross
Differential Revision: D28645999
fbshipit-source-id: 0e7a6c3e6c1b6c998f4b53fd89c744c84083dfb1
Summary:
Android was using rawProps received from JS, so no updates needed.
Updated iOS callsite to use the name of the action.
Changelog:
[General][Fixed] - Parse accessibilityAction props into object instead of string
Reviewed By: mdvacca
Differential Revision: D28614407
fbshipit-source-id: 209134f8fac65ca8516039e10ea502e57d52a7a7