Summary:
changelog: [internal]
If nodesManager has the information if animated node is managed by Fabric, we can't decide if the operation queue should be flushed before it is flushed. Therefore, keep the information about animated nodes inside a set instead of nodesManager.
For simplicity, I will refer to class `RCTNativeAnimatedTurboModule` as *NativeAnimated* and to `RCTNativeAnimatedNodesManager` as *NodesManager*
Notice that each call to *NativeAnimated* is queued up in `_operations` or `_preOperations`. When the queues are flushed, only then methods are called on `RCTNativeAnimatedNodesManager`.
There are two mechanisms that flush operations.
One is triggered by `RCTMountingManager` before mounting operations are applied and after they are applied. This works fine but is important to paint the picture.
The second mechanism is inside `[RCTNativeAnimatedTurboModule startAnimatingNode]`. It flushes the queues for Fabric nodes only (not sure why Fabric nodes only, I couldn't find any explanation in old diffs). It checks with *NativeAnimated* if a node is managed by Fabric. Keep in mind, *NodesManager* only knows about the nodes when the queues have been flushed.
Exampe:
JavaScript calls methods on *NativeAnimated*.
For example:
1. `createNode`
2. `connectAnimatedNodeToView`
3. `startAnimatingNode`. (here, the queues should be flushed, since we are in Fabric)
All of these operations are queued up and for as long as `RCTMountingManager` executes mounting, all proceeds as expected.
But if those operations happen after mounting phase, `startAnimatingNode` will not flush the operations queues, because it can't tell if nodeTag is managed by fabric or it isn't. This is because *NodesManager* hasn't been notified about any new nodes.
Reviewed By: JoshuaGross, p-sun
Differential Revision: D30053890
fbshipit-source-id: b7fe24861d5300f9cfefa813a53df8330fa56d86
Summary:
Merges the Facebook-internal Buck target definitions in `Libraries/` into the BUCK file at the root of the repo (which is currently not synced to GitHub at all). This does not affect how React Native is built in open source.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D27967499
fbshipit-source-id: 39c51a544b3868242598072d24cb6cfb5a6e2d8c
Summary:
Changelog: [internal]
Make sure the order of call is preserved for `NativeAnimatedModule`. The order of calls to NativeAnimatedModule needs to be preserved because its internals depend on it. For example, if you `getValue` is called before `createAnimatedNode`, it causes a crash.
To resolve it, we need to enqueue `getValue` onto operationQueue.
Reviewed By: JoshuaGross
Differential Revision: D30035911
fbshipit-source-id: bbd698a96cada5d2b1312a1a689ca99b04a07cdc
Summary:
This small PR updates the Flow types used in Dimensions. The following changes has been made:
* generic types has been replaced with types from `NativeDeviceInfo` (which already were used in event subscription update)
* ~simplification of `DisplayMetricsAndroid` by spreading via intersection with `DisplayMetrics` type and removing shared properties~
> I have tried both notations, but according to the lint, it looks like a Native Modules typing limitation which requires redundancy / code duplication in cases like this.
## 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] - update Dimensions API Flow types
Pull Request resolved: https://github.com/facebook/react-native/pull/31898
Test Plan: Running `yarn flow` in the workspace yields no errors.
Reviewed By: yungsters
Differential Revision: D29932940
Pulled By: GijsWeterings
fbshipit-source-id: bf97bb972964c585207e2450ccf71d932555e291
Summary:
It seems that, possibly due to optimizations and refactoring elsewhere in the event system, some TouchEvents are being over-disposed.
This doesn't really pose a problem besides performance; and could even indicate that an Event was in a pool but never properly initialized. In these
cases it seems perfectly reasonable to silently continue, and to log a soft exception. This WILL still crash in debug mode, so we can gather more information
if we find a good repro; otherwise we will continue to get production data from this soft exception if it's an issue and we can investigate further.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D30061178
fbshipit-source-id: 05d1f60afc382ce0a202ac8f3de34770cf9a760d
Summary:
Changelog: [Internal]
If generators are provided natively, that should suggest that the JS source
code did not go through the regenerator-transform (e.g. in Metro Hermes profile),
then there is no need to set up the regenerator runtime.
This should save some work during the Core initialization.
Reviewed By: motiz88
Differential Revision: D29986751
fbshipit-source-id: 129f5122e8e4c05535ee2aa5da6970a66843e8cd
Summary:
Changelog: [Internal]
This diff only extracted the `isNativeFunction` used in `setUpTimers`
into the `FeatureDetection` utility, but later we will add more functions
in it and reuse them in other places.
Reviewed By: RSNara
Differential Revision: D29986750
fbshipit-source-id: 6e48e38d92ceccb35eead3c52e00e1eecb81b5b0
Summary:
Moves the Facebook-internal Buck target definition for React Native closer to the actual JS source files. This does not affect how React Native is built in open source.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D27942687
fbshipit-source-id: 328febb661ed6597feafdfd8efb2a95365325348
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/31435
Moves the Facebook-internal Buck target definition for RNTester closer to the actual source files. This does not affect how RNTester is built in open source.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D27942209
fbshipit-source-id: 66c970a5464a9329597d155ceeca78fb7f4834e8
Summary:
This is the Android analogue to D30019833.
Changelog: [Internal]
Reviewed By: p-sun
Differential Revision: D30029295
fbshipit-source-id: 13df0dfb915697eeedcc527dcdb6c246e89afb0c
Summary:
Remove unused import
## 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
-->
[iOS] [performance] - Remove unused import
Pull Request resolved: https://github.com/facebook/react-native/pull/30544
Test Plan: Should build on CI
Reviewed By: lunaleaps
Differential Revision: D30000901
Pulled By: charlesbdudley
fbshipit-source-id: 3d3310917823b7af57564ca1ea397cd32cd0c4d5
Summary:
This diff updates the xplat flowconfigs to make existential types an error.
Changelog: [Internal]
Reviewed By: pieterv
Differential Revision: D29967838
fbshipit-source-id: f08bbafe2a0269adb2c9afa4572b7a34fd254a4d
Summary:
preferred instead of preffered
## 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
-->
[CATEGORY] [TYPE] - Message
Pull Request resolved: https://github.com/facebook/react-native/pull/29858
Reviewed By: charlesbdudley
Differential Revision: D29998754
Pulled By: sota000
fbshipit-source-id: f13fef58e9154ddf8087944d53e022fb9afa6b1b
Summary:
See previous diffs for context. This updates all of the relevant props structs.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29855426
fbshipit-source-id: 30177c3380ef82ecf8f2a4321f128cfbe8a576e0
Summary:
Unfortunately, parsing some props requires stateful context - namely, PlatformColor on Android. We explored several different options but they all seemed inferior to the approach of using ContextContainer, and most would require using global state.
By introducing this change everywhere as early as possible, we can avoid later pain. It is likely that some prop, on some platform, will require this mechanism. We'll be ready for it!
Because we can pass a constref of the ContextContainer through to all props and because the context and context data is never retained by prop parsers, perf and memory hit should be ~0.
This diff contains core changes only. Leaf changes to all props structs and conversions files will be in next diff(s).
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D29838789
fbshipit-source-id: f5090e7f02eb6e8fbe0ef4dd201e7d12104a3e3c
Summary:
occured -> occurred
## 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] [Fixed] - Fixed typo in VirtualizedList-test.js
Pull Request resolved: https://github.com/facebook/react-native/pull/31756
Test Plan: NONE
Reviewed By: lunaleaps
Differential Revision: D29975153
Pulled By: charlesbdudley
fbshipit-source-id: 966d90df0bf015b4a6a2e3b1bf88c66b61161a7a
Summary:
Fixes https://github.com/facebook/react-native/issues/31779
For more detailed explanation, see issue https://github.com/facebook/react-native/issues/31779
React Native touch handler events (onTouchStart, onTouchMoved, etc..) are intended to have "force" properties when used on devices which support pressure input (3D Touch & Apple Pencil events). However, due to a check in RCTForceTouchAvailable() function which checks for UITraitCollection's "forceTouchCapability" to be equal to UIForceTouchCapabilityAvailable, the check returns NO on iPad-based devices, due to iPad devices returning UIForceTouchCapabilityUnavailable at all times. This causes "force" values of Apple Pencils to never be passed on to React Native.
Since simply passing 0 as a value for force across the RN bridge for every touch event seemed like a change that might seem jarring to some, I decided that a simple additional boolean check if the touch event's type is UITouchTypePencil (this is the same as UITouchTypeStylus) should also suffice.
## 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
-->
[iOS] [Fixed] - Fixed "force" property of touch events for Apple Pencil/Stylus devices.
[iOS] [Feature] - Added "altitudeAngle" property to touch events from Apple Pencil/Stylus devices.
Pull Request resolved: https://github.com/facebook/react-native/pull/31780
Test Plan:
The code compiles and runs, and trying a simple handler for a View like
````
touchMove = (e: GestureResponderEvent) => {
console.log(`pressure, altitude (${e.nativeEvent.force}, ${e.nativeEvent.altitudeAngle})`);
````
results in
<img width="424" alt="Screen Shot 2564-06-28 at 17 13 22" src="https://user-images.githubusercontent.com/5000572/123621055-0b563f00-d835-11eb-9eff-526ba27fdf7b.png">
and when pencil is oriented perpendicular to the screen and pressed with full force shows
<img width="412" alt="Screen Shot 2564-06-28 at 17 13 58" src="https://user-images.githubusercontent.com/5000572/123621139-1c06b500-d835-11eb-8207-68a49720d708.png">
Reviewed By: sammy-SC
Differential Revision: D29964102
Pulled By: sota000
fbshipit-source-id: 5a1f41d64c6fe325afbd2b9579eaf20a522e92dc
Summary:
changelog: [internal]
Completion block can retain `_eventEmitter` beyond existence of the component. To fix this, do not retain `_eventEmitter` by block but try to acquire it inside it.
Reviewed By: JoshuaGross
Differential Revision: D29969189
fbshipit-source-id: 456c42f816acc160f9d6bbd3f9c8c55d611940b2
Summary:
Changelog: [Internal]
Historically, Immediate API is implemented upon the React Native's
internal microtask-y queue (known as "immediate queue"), which
is the same queue Promise polyfill is operating on.
To make React Native suitable of using the built-in Promises from JSVMs,
which usually enqueues to the JSVM internal microtask queue and has no
access to React Native microtask-y queue, we need to migrate the
Immediate API to use the JSVM microtask queue as well to preserve the
semantics of code relies on the interleaving of promises and immediates.
To do that, this diff implement a shim layer for immediate APIs via the
new `global.queueMicrotask` API (which enqueues to JSVM) in JS, by wrapping
the immediate callback into a "microtask callback", which validate the
`immediate ID` against `clearedImmediate` Set before invoking it.
Reviewed By: RSNara
Differential Revision: D29845305
fbshipit-source-id: c2ed3fed426a5316b1e0dfbfaad51706d1765d4d
Summary:
Changelog:
[General][Added] - Add global.queueMicrotask
`queueMicrotask` is a relatively recent API defined in the WHATWG HTML spec
and it's been widely adopted by all web browsers and Node.js.
This diff introduced it to React Native by polyfilling it via a lazily-allocated
resolved Promise, or calling directly into a fast path provided by Hermes.
Reviewed By: RSNara
Differential Revision: D29838852
fbshipit-source-id: 8c4378b1b713fb8b0da5e67f92ba2ea9838766f7
Summary:
Changelog: [Internal]
Separate the functionality of the isPackagerRunning() function into a new class PackagerStatusCheck with the intention of being able to use this without needing a DevServerHelper
Reviewed By: makovkastar, ShikaSD
Differential Revision: D29933318
fbshipit-source-id: d708bb987b08634015d6ee6b6c8989faba416c5a
Summary:
This diff fixes the Android View dimensions in VR
PixelUtil.toSPFromPixel and PixelUtil.getDisplayMetricDensity() are both using getScreenDisplayMetrics() to perform conversion of dimensions. This is not correct because we should take into consideration the density of the Context / Activity instead of the Screen. This problem didn't raise before in Fabric Android because it seems that android OS on phones usually share the scale between the screen and the Activity?
These two methods are only used in Fabric and they were introduced by D9583972 (https://github.com/facebook/react-native/commit/5c0da011cbaa788c52519f8091157ca6d87d8abb) and D9173758 (https://github.com/facebook/react-native/commit/8b5e3fc16b1e58441318b6ada629dcff572dd120)
As part of this diff I'm also deleting the method toSPFromPixel in favor of toDIPFromPixel because I noticed the usages of these methods are meant to use toDIPFromPixel()
changelog: [Internal] internal
Reviewed By: JoshuaGross
Differential Revision: D29864944
fbshipit-source-id: a0a093c120bde21a6cf9e1043a83c31e870d4368
Summary:
Currently, React Native throws an invariant violation error when a text string or number is supplied as a child. This is undesirable because core library components should be fault-tolerant and degrade gracefully (with soft errors, if relevant).
This change will work when a change in the host configs are landed (https://github.com/facebook/react/pull/21953).
Changelog: [internal]
Reviewed By: yungsters, sammy-SC
Differential Revision: D29894182
fbshipit-source-id: 827ff299991a476b57981382d196c7ee1396ec28
Summary:
Some of the links in `CONTRIBUTING.md` redirects you to a different page.
I've fixed the links so each link would directly send users to the appropriate page.
## 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] - update links in CONTRIBUTING.md
Pull Request resolved: https://github.com/facebook/react-native/pull/31903
Test Plan: - [ ] Change links shows the appropriate content
Reviewed By: lunaleaps
Differential Revision: D29933105
Pulled By: GijsWeterings
fbshipit-source-id: b5be74181f8a8e88d8f43e44c469337b7393dedf
Summary:
Part of https://github.com/facebook/react-native/issues/31788
~Updated link in README that was pointing to master branch to main branch~
Realized that link in rn-tester README and ReactAndroid README leads to a dead link, so I've fixed the links
## 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] [FIXED] - Fix dead links in README
Pull Request resolved: https://github.com/facebook/react-native/pull/31901
Test Plan: - [ ] Updated link directs you to appropriate page
Reviewed By: PeteTheHeat
Differential Revision: D29933044
Pulled By: GijsWeterings
fbshipit-source-id: c1f301626acbb2995d74f78d8bc19214c70e9319
Summary:
Changelog: [internal]
Fabric didn't have prop [removeClippedSubviews](https://reactnative.dev/docs/view#removeclippedsubviews) implemented. This diff adds it. It is
Reviewed By: JoshuaGross
Differential Revision: D29906458
fbshipit-source-id: 5851fa41d7facea9aab73ca131b4a0d23a2411ea
Summary:
Changelog: [Internal]
This diff replaced all the internal occurrences of "Immediate" with
"ReactNativeMicrotask" in the legacy bridge and then polyfilled the
original immediate APIs during the timer setup phases as aliases of them.
Note that this diff is part of a larger refactoring.
Reviewed By: RSNara
Differential Revision: D29785430
fbshipit-source-id: 7325d2a7358a6c9baa3e9abb8acf90414de5072f
Summary: Changelog: [Internal] - Add an example to demo all the transform properties.
Reviewed By: charlesbdudley
Differential Revision: D29865790
fbshipit-source-id: 79174457071de8fca9b0aab8bf8dcc543ea9a0a3
Summary:
- Update `RNTesterNavBar` to be positioned relatively to allow for scroll views to not be clipped
- Add EasingExample with example animations taken from https://reactnative.dev/docs/easing
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D29744160
fbshipit-source-id: d0e2112769d74dd34e11477f1d3b1f8f0ffebc03
Samuel Susla
Pieter De Baets
Moti Zilberman
Test User
Joshua Gross
Xuan Huang
David Vacca
Vegas Murphy
Ramanpreet Nara
fabriziobertoglio1987
jeswinsimon
Jacob Parker
Evan Yeung
Michael Chow
CodemodService FBSourceClangFormatLinterBot
Ikko Ashimine
swittk
Amy Nichol
Rick Hanlon
Sota Ogo
Jesse Katsumata
Charles Dudley
Luna Wei
