Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46832
After bumping to minIOSVersion 15.1, we refactored the code to remove some check.
In the refactoring, we changed how the `keyWindow` is returned and now we are unsafely casting `UIScene` to `UIWindowScene`.
We have some internal apps that use `UIScene` that are not `UIWindowScene` and the change is causing them to crash.
This change fixes the crash by checking whether the selector is available in the UIScene and casting it only in that case.
Otherwise we return `nil`, the same behavior we used to have before the refactor.
## Changelog
[iOS][Fixed] - Cast the UIScene to UIWindowScene only if the scene respond to the selector
Reviewed By: javache
Differential Revision: D63890980
fbshipit-source-id: 3230e0075f06ed3f3d759b48f9c7bd13d8787b44
Summary:
Part of this: https://github.com/facebook/react-native/issues/46757
Solves:
- ME2E0011
- ME2E0012
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[ Internal ] [ Added ] - Add e2e test for button
Pull Request resolved: https://github.com/facebook/react-native/pull/46805
Test Plan:
```
yarn e2e-test-ios
yarn e2e-test-android
```
Reviewed By: cortinico
Differential Revision: D63829243
Pulled By: cipolleschi
fbshipit-source-id: 87d8e62650c66fb07e116877a212eff79f10eaf2
Summary:
This PR moves `RCTNotifyEventDispatcherObserversOfEvent_DEPRECATED` as it was used as string in the codebase and in OSS libraries.
## Changelog:
[IOS] [FIXED] - move RCTNotifyEventDispatcherObserversOfEvent_DEPRECATED to const
Pull Request resolved: https://github.com/facebook/react-native/pull/46833
Test Plan: CI Green
Reviewed By: cipolleschi
Differential Revision: D63891220
Pulled By: javache
fbshipit-source-id: d4fa1f751b4b0cb131ab6c6d4dd0a345762d7c71
Summary:
I discovered this while working on my shim of `UIGraphicsImageRenderer` for macOS (See https://github.com/microsoft/react-native-macos/pull/2209). A variable of type`CGColorRef` is not automatically retained and released when passed into a block. There was a case in `RCTBorderDrawing` where we were doing so. To fix this, we have two options:
1. Pass a `UIColor` instead (Requires a change to the signature of the function calling it)
2. Properly retain and release the variable.
The first option would technically be a breaking change (we would need to change the signature of `RCTGetBorderImage`, so I'm opting for option 2.
## Changelog:
[IOS] [FIXED] - Properly retain/release backgroundColor in RCTBorderDrawing
Pull Request resolved: https://github.com/facebook/react-native/pull/46797
Test Plan: CI should pass. Locally, borders still draw fine for me.
Reviewed By: joevilches
Differential Revision: D63827824
Pulled By: cipolleschi
fbshipit-source-id: 926601d062b90a7d741d7a1af3070cec4b8795ae
Summary:
This fixes an issue where `POST /open-debugger?appId&device&target` does not return a proper status code, meaning that the request will never be answered and clients might hang until the request timeout is hit.
## Changelog:
<!-- Help reviewers and the release process by writing your own changelog entry.
Pick one each for the category and type tags:
[ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message
For more details, see:
https://reactnative.dev/contributing/changelogs-in-pull-requests
-->
[GENERAL] [FIXED] - Respond with status code `200` when successfully launching RNDT
Pull Request resolved: https://github.com/facebook/react-native/pull/46814
Test Plan:
- `curl -v -X POST "<deviceUrl>"`
- This should show a proper response for the request.
before | after
--- | ---
 | 
Reviewed By: NickGerleman
Differential Revision: D63837025
Pulled By: huntie
fbshipit-source-id: ac72fc793e015f0eec498f4a35b4fb9e301c5b32
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46787
This issue was raised by a some partner that were integrating with libraries that were setting the wrong C++ version.
With this change, RN takes ownership of the version of C++ that must be supported.
## Changelog
[iOS][Breaking] - Cocoapods decide the C++ version for iOS pods
Reviewed By: blakef
Differential Revision: D63760271
fbshipit-source-id: 5e629c61accd97fb10a199430d31e8b4c73d482b
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46160
We use this for all built-in components now, and rely on going through `BackgroundStyleApplicator` to be able to set additional background effects like borders, rounded corners, box shadow, outlines.
Let's use this in `BaseViewManager`, to allow exposing those other effects to all views, letting RN manage the background drawable for views using `BaseViewManager` and exposing the props for the managed styles.
This is technically breaking, in the case where a custom component could previously inherit directly from `BaseViewManager`/`ReactViewGroupManager`, (vs `SimpleViewManager`/`ReactViewManager`), then override `setBackgroundColor` on the Android View, instead of the view manager, but this effected zero of the [276 top libraries](https://github.com/elicwhite/react-native-libraries), so I don't think it would be common to hit.
Changelog:
[Android][Breaking] - Use BackgroundStyleApplicator when setting background color in BaseViewManager
Reviewed By: tdn120
Differential Revision: D61658739
fbshipit-source-id: 15af649328ea18fda3cd68e56d481ed1c0fd43c4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46800
X-link: https://github.com/facebook/yoga/pull/1716
Had a mini heart attack thinking I set the default to content box. Wrote this to double check and it passed. Might as well check it in
Technically the default to BoxSizing.h is ContentBox, but in the style we override that. Regardless I switched that around so border box was the default.
Changelog: [Internal]
Reviewed By: NickGerleman
Differential Revision: D63802722
fbshipit-source-id: 49ed29657c964bc12a2bf70988061ab4599267ec
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46712
## Summary
Now that XML resources are loaded via Fresco decoder, this change removes the custom branch that attempts to load drawables on the main thread. Loading (i.e. binary XML decompression) is performed on a background decoder thread from Fresco the same as every other image type.
## Changelog
[Android][Fixed] - Avoid blocking the main thread when decompressing drawable resources
Reviewed By: javache
Differential Revision: D63476282
fbshipit-source-id: a8510d140f85a55b90bf4aab6fd4cf5e46dfc7fd
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46812
Convert to Kotlin as close a 1:1 as possible.
Changelog: [Internal]
Reviewed By: alanleedev
Differential Revision: D63773448
fbshipit-source-id: 72d67ec5993ffb225b016937e6a33fc8d4a8af16
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46763
Changelog: [Internal]
[iOS][DeprecatedAPI] - Deprecate UIApplication.windows access for iOS versions higher than 13.0
> 'windows' is deprecated: first deprecated in iOS 15.0 - Use UIWindowScene.windows on a relevant window scene instead [-Werror,-Wdeprecated-declarations]
Reviewed By: cipolleschi
Differential Revision: D63708635
fbshipit-source-id: 18cfeda89def996319a46573abeb88d4672f6c0d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46811
I turned this off a few weeks after we turned off in FB app in (D60273063), after discovering it defeated a check used to disable `removeClippedSubviews` in RTL (reintroducing its bugged behavior).
D63318754 fixed that bug, so this is turning back on by default. This is also needed to fix border rendering direction bug introduced in BackgroundStyleApplicator in views where the contextual layout direction is different from the root Android layout direction (either because of `direction`, or `I18nManager` forceRTL). This fixes some existing RNTester RTL screenshot test failures which are hooked via forceRTL.
This also fixes rendering of some native components like `Switch` which would previously not respect contextual direction.
Changelog:
[Android][Fixed] - Reenable `setAndroidLayoutDirection` by default
Reviewed By: javache
Differential Revision: D63815077
fbshipit-source-id: fea64191d83d366c6bfc7b8c58b215773c8e8efe
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46613https://github.com/facebook/react-native/commit/bd323929dc5be5666ee36043babec7d981a095dc added a workaround to a bug where Android new arch would return incorrect measurements when the last character in dynamically sized TextInput is a newline. This workaround works by adding a placeholder character after any trailing newlines.
Apart from a minor oversight in the impl (unnecessary `toString()` copying text on every layout), approach of mutating Spannable will create problems for `PrecomputedText`, where we want to avoid mutating Spannable after set in more common cases for normal text (though mutation must happen for a few other cases, like adjustment, or EditText).
The real root cause of the issue is that StaticLayout tries to derive the size of text for area outside of what is covered by the Spannable (whose last char is the newline, considered on the previous to last line). This causes it to use text size, family, etc from `TextPaint`, which does not have this information set in new arch (the font size (but oddly nothing else) is set in Paper).
This updates TextLayoutManager to set this information on TextPaint before creating a layout. Because TextPaint is now mutable, and TextLayoutManager can be called by multiple threads, I made the variable thread local to avoid concurrent mutation. We also have the cached Spannable scenario where we have already lost the AttributedString, but in this case, we can reuse the underlying EditText paint, which I associate with the underlying cached Spannable.
I also marked a few more methods in TextLayoutManager private which nothing else is calling, to be able to better reason.
A followup, is that `ReactTextInputManager` sets all of these extra fields on the `EditText` paint (so those will be consistent), but `ReactTextAnchorViewManager` does not set all of these, so its underlying TextView would normally show newlines with an inconsistent size compared to the attributes present (though I don't think it much matters if we add the right amount of extra space to the actual layout).
Changelog:
[Android][Fixed] - Properly fix measurement of trailing newlines
Reviewed By: cortinico, mdvacca, mellyeliu
Differential Revision: D63303172
fbshipit-source-id: 63e5e24bce7fe8866524171d9acfc8f13e1efffc
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46612
This information is lost by the time the AttributedString makes its way to be measured.
Pretty sure I've seen code do incorrect heuristics like grabbing first span for this (IIRC adjustFontSizeToFit does this)? Another case where we hit this on Android is when the last character is a newline (which is part of the Spannable), and layout needs to predict the size of the line which will come next (where it uses the EditText's underlying TextPaint, who is using these base attributes).
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D63303709
fbshipit-source-id: 644a97c80a9280e643514786ea6cf32faa4f1cf8
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46711
## Summary
Vector drawable decompression is a blocking operation and can sometimes take upwards of 20-30ms per image, especially if that vector drawable uses complex colors. Less complex vector drawables still take several milliseconds to decompress and are served from a cache on later load attempts.
Here's a list of all the load times of vector drawable images in FBVR:
{F1891592104}
This diff aims to shift decompression to one of Fresco's decode threads, off the main thread, so we don't block while waiting for decompression operations to complete. This relies on adding a new custom decoder that reads the header of XML binary and converts encoded image requests to drawable objects that are yielded from the new `XmlDrawableFactory`.
It's important to note that this change does not stop `ReactImageView` from loading XML-based drawables on the main thread, it merely offers a new mechanism for loading them.
## Changelog
[Android][Added] - Add a new Fresco decoder for XML resource types
Reviewed By: mdvacca
Differential Revision: D63476283
fbshipit-source-id: b0f9b5af42254bcf038a9eb088e7d72dd39cdb51
Summary:
While digging through the types I came accross this TODO. Now that react-native uses version 5 of TS this can be updated
## Changelog:
[General] [Added] - Updated FlatList setNativeProps type
Pull Request resolved: https://github.com/facebook/react-native/pull/46773
Reviewed By: NickGerleman
Differential Revision: D63765333
Pulled By: cipolleschi
fbshipit-source-id: ad612205d168cd90f270da72092f8ce67f5038c4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46789
GitHub is reporting those warnings on each pull request. This clears them up as they're effectively unused.
Changelog:
[Internal] [Changed] - Remove several unused imports in Flow code
Reviewed By: cipolleschi
Differential Revision: D63757201
fbshipit-source-id: 21189136a03de8899adcbf18c8f0e29844ade340
Summary:
On the old architecture you could take control of loading the bundle by implementing
```objc
- (void)loadSourceForBridge:(RCTBridge *)bridge
onProgress:(RCTSourceLoadProgressBlock)onProgress
onComplete:(RCTSourceLoadBlock)loadCallback;
```
in your `RCTBridgeDelegate`. This is not currently possible in the new architecture.
I've added this using a pretty much identical api by adding a function to both the `RCTInstanceDelegate` and `RCTHostDelegate` protocols. This will be called on the `RCTRootViewFactory`. I've added two properties to the `RCTRootViewFactoryConfiguration`, `loadSourceForHost` and `loadSourceWithProgressForHost`. If one is present, we call it, otherwise we fallback to the normal loading process
## Changelog:
[iOS] [Breaking] - Add ability to control bundle loading on the new architecture similar to `loadSourceForBridge`. Removed some properties from the `RCTRootViewFactory`.
Pull Request resolved: https://github.com/facebook/react-native/pull/46731
Test Plan: Rn-tester works as normal and it is working for our use case in expo go.
Reviewed By: blakef
Differential Revision: D63755188
Pulled By: cipolleschi
fbshipit-source-id: f1f26b2775b9e547ce7a23028665797c19bfdd9b
Summary:
Because `UIGraphicsImageRenderer` doesn't exist on macOS, I need to shim it for React Native macOS (See https://github.com/microsoft/react-native-macos/pull/2209). I planned to use the name `RCTUIGraphicsImageRenderer`. However.. it seems that is used by a static helper function in `RCTBorderDrawing.m`. So.. let's rename it? The function is just a helper method to make an instance of the class, so I think the name `RCTMakeUIGraphicsImageRenderer` is slightly more idiomatic anyway.
This method is not public, so it should not break the public API of React Native.
## Changelog:
[IOS] [CHANGED] - Rename `RCTUIGraphicsImageRenderer` to `RCTMakeUIGraphicsImageRenderer`
Pull Request resolved: https://github.com/facebook/react-native/pull/46772
Test Plan: CI should pass
Reviewed By: joevilches
Differential Revision: D63765490
Pulled By: cipolleschi
fbshipit-source-id: de68dce0f92ec249ea8586dbf7b9ba34a8476074
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46806
This fixes the CI which is currently red due to wrong C++ imports.
Changelog:
[Internal] [Changed] - Unbreak build_android
Reviewed By: javache, cipolleschi
Differential Revision: D63826953
fbshipit-source-id: 4d9e407331af666a420cf56178420df40e598ef4
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46794
Original commit changeset: f57e9a51236c
Original Phabricator Diff: D63430964
Seeing some issues with this so gonna turn it off for the meantime.
Changelog: [Internal]
Differential Revision: D63777437
fbshipit-source-id: fe8abd0110b2cf7296911c5b1e95ada40d30994c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46795
Original commit changeset: d7bb6f115bca
Original Phabricator Diff: D63471840
See previous diff, there were some problems
Changelog: [Internal]
Differential Revision: D63777438
fbshipit-source-id: ea9f370eade10282fcee84d07d709b549dde1b6d
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46736
Copying the comment in code:
> We only call `onEndReached` after we render the last cell, but when getItemLayout is present, we can scroll past the last rendered cell, and never trigger a new layout or bounds change, so we need to check again after rendering more cells.
Changelog:
[General][Fixed] - Fix onEndReached not being called when getItemLayout is present and we scroll past render window
Reviewed By: yungsters
Differential Revision: D63643856
fbshipit-source-id: 9c53789cb15b225ceac353c37cbb67f7beeaf4fb
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46793
Currently performance logging has several problems:
- We have widly different APIs. It's hard to know which to use for what.
- Most of these APIs don't allow retroactive timestamp which is important for hero logging and react flame graphs
- These APIs aren't accessible from JS/C++/Java/Koltin (this part will be fixed in another diff)
- Logging doesn't go to the right place. It either only goes to Systrace, or Perfetto but with broken async timeline etc...
This diff start addressing the problem by refactoring. Currently performance.measure/performance.mark are the best APIs. Let's start with refactoring them so that we can call them directly without the otherwise PerformanceEntry side effects.
Changelog: [Internal]
Reviewed By: cortinico
Differential Revision: D63560473
fbshipit-source-id: 86755b3e8491a7cf6919173a07ba9421cd30e663
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46788
Changelog: [internal]
This fixes the reported keys for C++ TurboModules:
```
import MyNativeCppModule from 'MyNativeCppModule';
Object.keys(MyNativeCppModule); // [] - expected
Object.keys(Object.getPrototypeOf(MyNativeCppModule)); // [] - NOT expected
```
Before, we were trying to read the properties from the method map in the public `TurboModule`, but in this implementation all the logic is actually in its delegate (also a `TurboModule` instance, yeah, confusing).
This fixes the issue by forwarding the call to the delegate that has the right information.
Reviewed By: javache
Differential Revision: D63761381
fbshipit-source-id: 90bd216efa0f60352c5ca341d210d83239c80dba
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46785
changelog: [internal]
Make sure logs match the class name
Reviewed By: rubennorte
Differential Revision: D63757693
fbshipit-source-id: 815e70e8ae38d99b1908d3aa2a9cfffdd9dc9851
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46780
This is primarily a debugger server change to better-align the `title` and `description` fields (visible in via the CDP `/json/list` endpoint), reporting them directly from the device.
For React Native users, the net effect of this change is to improve/align the display name for each debugger target in the CLI multi-select menu (`j` to debug). This change may also be useful for discovery in non-Fusebox frontends such as VS Code (`vscode-expo` extension).
Changes:
- Rename `title` prop on `InspectorPageDescription`/`IInspector::addPage` to `description` (no call site changes).
- Add `deviceName` param to `InspectorPackagerConnection`.
- Move the page `description` to the `description` JSON field.
- Update `InspectorPackagerConnection::Impl::pages()` to return new `title` and `description` fields.
- Align `OpenDebuggerKeyboardHandler` to display `title` field.
- Deprecate the nonstandard `deviceName` field.
**Before**
```
[
{
"id": "3c9f24bedab0e73fca6a1b295030e7af9346a8c0-1",
"title": "React Native Bridgeless [C++ connection]",
"description": "com.facebook.RNTester",
...
}
```
The `description` field was previously the closest thing we had to a target identifier. Today, this is not needed, since we have the stable `reactNative.logicalDeviceId` field.
**After**
```
[
{
"id": "3c9f24bedab0e73fca6a1b295030e7af9346a8c0-1",
"title": "com.facebook.RNTester (iPhone 16 Pro)",
"description": "React Native Bridgeless [C++ connection]",
...
}
```
The `title` field is now more human readable and aligned with what we render in the window title of React Native DevTools. The `description` field describes the type of debugger target (the specific React Native implementation).
Changelog: [Internal]
Reviewed By: vzaidman
Differential Revision: D63329456
fbshipit-source-id: cfe98f77e31c729431005925cfc66e2780ef8c72
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46782
changelog: [internal]
Avoid setting C++ state for the same contentOffset. This is redundant work and can be safely avoided.
Reviewed By: NickGerleman
Differential Revision: D63700308
fbshipit-source-id: d6ea8cf6a1da47a13787b49abd66a87e3da57d34
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46778
This has been rolled out internally already and is a good cleanup for OSS too. We no longer use this config externally (BRIDGE+FABRIC) so this shouldn't actually affect the new arch rollout.
Changelog: [Internal]
Reviewed By: fabriziocucci
Differential Revision: D63752084
fbshipit-source-id: da3025f7b072dc7b82f8de22ff247b3979ae64d0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46776
All other paths that touch `mAttachedReactRoots` uses this lock. We expect this to address a crash we're seeing in production where `startSurface` is invoked multiple times.
Changelog: [Internal]
Reviewed By: fabriziocucci
Differential Revision: D63752083
fbshipit-source-id: f06d07aa70719945f6956fbf6e0cde3e9c8e8ed0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46751
rubennorte noticed that some turbo module methods were not getting cached on the jsRepresentation as expected. This is caused by the react-native-codegen wrappers we generate overriding the `get` method and bypassing this caching layer. Instead they should be overriding `create` to lazily allocate new properties. To prevent this from re-occuring, I've made `get` final so no other overrides can happen.
## Changelog:
[General][Fixed] Properties for C++ TurboModules using codegen were not correctly cached
[General][Breaking] TurboModule::get is now a final method, override `create` to customize property lookup
Reviewed By: rubennorte
Differential Revision: D63665966
fbshipit-source-id: c614901c2f0d698147ec9ba36a4b592ed3d37652
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46697
Changelog: [internal]
This is already the case in `PerformanceMeasure` but for some reason we didn't apply it here as well.
Reviewed By: rshest
Differential Revision: D63541134
fbshipit-source-id: 262d504ed153e07e89492945f761887729bad9e0
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46698
Changelog: [internal]
Small optimization to use readers/writers for locking in `PerformanceEntryReporter`.
Reviewed By: rshest
Differential Revision: D63540236
fbshipit-source-id: 80b3fd313453ad8da4f0af2deaab61a86064b4b7
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46693
Changelog: [internal]
This unifies the native modules for `Performance` and `PerformanceObserver` in the same module. Keeping them separate is artificial and introduces unnecessary duplication. These APIs are very closely related so it makes sense to unify
Reviewed By: javache
Differential Revision: D63471855
fbshipit-source-id: fa8c5dc7b7c68954fc11867f68909d2c6c2ee85c
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46760
Changelog: [internal]
Relying on the singleton was causing issues in iOS tests for RuntimeScheduler. This fixes those issues.
Reviewed By: rshest
Differential Revision: D63702251
fbshipit-source-id: 42b98e673ffba6f45b52510cdb3eea410e55b894
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46688
Changelog: [internal]
Just aligns on `report*` as the public API in `PerformanceEntryReporter` (e.g.: `measure` -> `reportMeasure`, `logEventEntry` -> `reportEvent`, etc.).
Reviewed By: rshest
Differential Revision: D63471856
fbshipit-source-id: 59617160c238aaefaefe8b6fc27de4481ef32ada
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46714
Sets up a feature flag to experiment with scheduling `Animation` completion callbacks in a microtask instead of executing them synchronously. (The completion callback is the callback passed into `animation.start(<callback>)`).
There are currently 4 potential scheduling behaviors of the animation completion callback:
- Synchronously when `start()` is invoked, for spring and timing animations that immediately complete (e.g. no delays and not native driver).
- Synchronously when `stop()` is invoked, if the animation has not yet completed.
- Synchronously during the layout effect phase, or commit phase (if the `useInsertionEffectsForAnimations` feature flag is enabled), if the animation has not yet completed.
- Asynchronously when the animation completes (e.g. non-zero delay or when the native driver is employed).
The wide number of variables and the timing-dependent nature of these variables means that the behavior of the completion callback is very non-deterministic.
Imperically, we have also found that most codebases using `useNativeDriver` mostly have completion callbacks executed asynchronously. However, this leads to surprising problems where the callback causes unpredictable behavior when it is called synchronously (e.g. when the animating component is unmounted *during* the animation).
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D63573322
fbshipit-source-id: 16c48be78c9ac65a64021249fad10f7265737c44
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46718
Simple rename of a protected method that should not be called by anyone outside of the `Animation` class and its subclasses, just to make it more intuitive.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D63572363
fbshipit-source-id: cf68f63a9b361767b9dbfcd73124bcdae7a1806e
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46717
Reduces redundancy and cleans up the layers of abstraction between the `Animation` class and its subclasses, by hoisting common and duplicated logic into the parent class.
I also cleaned up the Flow types in these files while I was at it.
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D63572064
fbshipit-source-id: ab6bf7265b67ab38cc5a9d5c94f8cd1456c93f23
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46720
Refactors the `Animation` subclasses (from Animated) such that using `useNativeDriver` with a non-native `AnimatedValue` will consistently fail when calling `start()`.
The current behavior is inconsistent because if a timing or spring animation has a non-zero delay, the error will be thrown in asynchronously in a timeout.
Changelog:
[General][Changed] - Animations started with incompatible `useNativeDriver` and `AnimatedValue` configurations will now synchronously fail. Previously, spring and timing animations with non-zero delays would throw the error asynchronously.
Reviewed By: javache
Differential Revision: D63572062
fbshipit-source-id: 2619e2867fe7754695e3347c838ad6fe136a6614
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46719
Implements a minor refactor of `TimingAnimation#start` so that we standardize how the `_useNativeDriver` case is handled.
There is no behavior change from this besides more consistently assigning to `this._startTime`. (Previously, we would not set it if the duration were 0 and `!useNativeDriver`.)
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D63572066
fbshipit-source-id: 9cbd05c5ca5e00227be69441b9d7d8a502690246
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46716
Changes `_nativeId` to be a private property in the `Animation` class (from Animated).
Changelog:
[Internal]
Reviewed By: javache
Differential Revision: D63572065
fbshipit-source-id: 24facca0ccb1256f602ec4406bf8c0b22c4bbf96
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46721
Currently, the `Animation` class (from Animated) defines an unofficially protected `__onEnd` property that subclasses are expected to populate. However, subclasses are expected to *not* invoke `__onEnd`, but instead call `__debouncedOnEnd`.
In order to make this code less fragile, this commit refactors the `Animation` class and its subclasses so that `onEnd` is stored in a private property and initialized by the `start` method in the `Animation` parent class. Now, the only way to invoke the `onEnd` callback is by calling `__debouncedOnEnd`.
The subclasses have been adjusted to call the `start` superclass method to initialize this.
Changelog:
[General][Changed] - The `Animation` superclass no longer exposes `__onEnd` as a property. Subclasses must instead invoke `super.start(…)` in their `start()` implementation.
Reviewed By: javache
Differential Revision: D63572063
fbshipit-source-id: 221153ca890c67c59713d607032536f57d7a5b0a
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46715
Properly mocks `NativeAnimatedModule` in Jest so that we can cleanup the `process.env.NODE_ENV` checks in Animated.
Changelog:
[General][Added] - Added Jest mocks for `NativeAnimatedModule`
Reviewed By: javache
Differential Revision: D63572067
fbshipit-source-id: a4fcedeebbaaa47a34bb356305652a3ed6358855
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/46742
Migrates type definitions in React Native to use the newly created `HostInstance` type instead of `NativeMethods` and `React.ElementRef<HostComponent<T>>`.
Changelog:
[General][Changed] - Simplified Flow types to use `HostInstance` (which changing nominal types).
Reviewed By: NickGerleman
Differential Revision: D63646763
fbshipit-source-id: 904894dc40da4d2e70bcb6df47018fc6248ea972
Riccardo Cipolleschi
Yasir
shubhamguptadream11
Oskar Kwaśniewski
Saad Najmi
Cedric van Putten
Nick Gerleman
Joe Vilches
Peter Abbondanzo
Thomas Nardone
Cao Doan
JDMathew
Nicola Corti
Sam Zhou
Alan Hughes
Gabriel Donadel
Alex Hunt
Benoit Girard
Rubén Norte
Samuel Susla
Pieter De Baets
Tim Yung