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:
Fixed a link in a comment that lead to dead link
whatwg-url changed the source directory from `lib` to `src`
## 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 link in a comment
Pull Request resolved: https://github.com/facebook/react-native/pull/31902
Test Plan: - [ ] Changed URL opens properly
Reviewed By: charlesbdudley
Differential Revision: D29915170
Pulled By: lunaleaps
fbshipit-source-id: 00b69db82f51d16cf887cd4540a159132ad7d771
Summary:
* it says focusTextInput but the function name is blurTextInput
* probably the message was copy-pasted from `focusTextInput` where is the same error message.
Changelog: [Internal]
Reviewed By: arhelmus
Differential Revision: D29845922
fbshipit-source-id: 21fd3e572c32779c13f6909556153d07dc7a416f
Summary:
Fix for https://github.com/facebook/react-native/issues/27952.
Noticed more than just `AUTOFILL_HINT_NEW_PASSWORD` were missing, this PR will support every `AUTOFILL_HINT_*` type.
## Changelog
[Android] [Added] - Added all autofill types to TextEdit
Pull Request resolved: https://github.com/facebook/react-native/pull/28008
Reviewed By: sturmen
Differential Revision: D29766235
Pulled By: mdvacca
fbshipit-source-id: d5171aef8092d37716fddcb6f3443637a4af8481
Summary:
Changelog:
[General][Added] - Added data field to markerPoint to allow callers to add additional arbitrary string data to logged points
Reviewed By: dmitry-voronkevich
Differential Revision: D29764274
fbshipit-source-id: b0d21e3b20a5353351424afb10c950f3e8689887
Summary:
This change adds a series of snapshot tests to validate the render output of VirtualizedList in mixed scenarios. Jest timer mocks are used to measure rendering at different ticks. These test cases mostly center around realization logic, to help prevent regressions when chaning internal state representation.
## 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] [Added] - Add unit tests for VirtualizedList render quirks
Pull Request resolved: https://github.com/facebook/react-native/pull/31401
Test Plan: Ran the added UTs locally.
Reviewed By: lunaleaps
Differential Revision: D28017750
Pulled By: rozele
fbshipit-source-id: df9684c4ac80a8732f3e88e7496815127213832e
Summary:
1. [ios] upgrade folly to 2021.06.28.00 which aligned to android.
2. folly compile setting from c++14 -> c++17: _this folly requires c++17 for `std::unordered_map::insert_or_assign`._
3. boost 1.63.0 -> 1.76.0: _the old boost does not support c++17._
4. deprecating react-native-community/boost-for-react-native: _by cocoapods installer, we could download the official target._
## Changelog
[iOS] [Changed] - Upgrade folly to 2021.06.28.00 and boost to 1.76.0
Pull Request resolved: https://github.com/facebook/react-native/pull/31840
Test Plan: CI passed
Reviewed By: fkgozali
Differential Revision: D29668480
Pulled By: yungsters
fbshipit-source-id: 98eae9ca47f489dcea91974e6f5e9dcb4d66c40c
Summary:
Android react-native `TextInput` component does nothing if prop `keyboardType` is `url` value. This PR solves that problem.
## Changelog
[Android] [Added] - Add support to URI keyboard type in Android
Pull Request resolved: https://github.com/facebook/react-native/pull/31781
Test Plan:
Before change:
{F630980679}
After Change:
{F630986399}
Reviewed By: lunaleaps
Differential Revision: D29517822
Pulled By: sshic
fbshipit-source-id: 1bda29584a3799570f34e772b5589b59ac80c524
Summary:
Updates documentation in React Native to reference `main` (or `HEAD` for URLs) instead of `master`.
Part of https://github.com/facebook/react-native/issues/31788.
Changelog:
[General][Changed] - Update documentation reference from `master` to `main` or `HEAD`.
Reviewed By: JoshuaGross
Differential Revision: D29717128
fbshipit-source-id: 0b0babd8407c6fd3d0e5431f6eaf976059731d6f
Summary:
Issue https://github.com/facebook/react-native/issues/30964 .When using a screen reader, flatlist does not announce entrance/ exit from the flat list.
## Changelog
[Android] [Changed] - Added support for accessibility role of "list" for flatlist and sectioned list
Pull Request resolved: https://github.com/facebook/react-native/pull/31630
Test Plan: I have added accessibility role prop in flatlist and sectioned list in rntester app, that will announce entrance/ exit from flatlist and sectioned list.
Reviewed By: kacieb
Differential Revision: D29599351
Pulled By: blavalla
fbshipit-source-id: e16ec69a694780d12f15f88a1e6bb5d7d77ac15f
Summary:
Add animation queuing back into createAnimatedComponent_EXPERIMENTAL.js, which is a concurrent-safe version of createAnimatedComponent.
T93269035 for details on why this is needed.
# How does this work?
In the old createAnimatedComponent, Animations were queued by calling `setWaitingForIdentifier` before render, and then calling `unsetWaitingForIdentifier` after render.
In this diff, instead we are calling `setWaitingForIdentifier` in an `useLayoutEffect` before calling `useAnimatedProps`, and we are calling `unsetWaitingForIdentifier` in a `useEffect` after `useAnimatedProps`. So the ordering for the effects are:
1. `useLayoutEffect` with `setWaiting`
2. `useLayoutEffect`s in `useAnimatedProps`
3. `useEffect`s in `useAnimatedProps`
4. `useEffect` with `unsetWaiting`.
There's a React guarantee that **if one effect is called, all of them will be called**, so we don't have a concern about the queue getting locked.
## **Main concerns:**
1. This works in my test cases, but it's not the same behavior as the old createAnimatedComponent (which is wait before and unset wait after render). This may still be ok because the relevant side effects in render from that component have been moved to `useLayoutEffect` or `useEffect` in `useAnimatedProps` (so the ordering is still the same?).
2. I'm not sure about the ordering of `onLayoutEffect`, `onLayout` callbacks, and `useEffect`. createAnimatedComponent_EXPERIMENTAL doesn't use `onLayout`, but with this new method of queuing, **`onLayout` calls will likely be called before the animation queue has been flushed**. It's not clear to me whether this is bad.
Changelog: [Internal]
Reviewed By: yungsters
Differential Revision: D29467458
fbshipit-source-id: 2be23a8968404526d0fa394a7879fda8b5ffbfdc
Summary:
iOS 13 added a new property to `UIScrollView`: `automaticallyAdjustsScrollIndicatorInsets`, which is `YES` by default. The property changes the meaning of the `scrollIndicatorInsets` property. When `YES`, any such insets are **in addition to** whatever insets would be applied by the device's safe area. When `NO`, the iOS <13 behavior is restored, which is for such insets to not account for safe area.
In other words, this effects ScrollViews that underlay the device's safe area (i.e. under the notch). When `YES`, the OS "automatically" insets the scroll indicators, when `NO` it does not.
There are two problems with the default `YES` setting:
1. It means applying `scrollIndicatorInsets` to a `ScrollView` has a different effect on iOS 13 versus iOS 12.
2. It limits developers' control over `scrollIndicatorInsets`. Since negative insets are not supported, if the insets the OS chooses are too large for your app, you cannot fix it.
Further explanation & sample code is available in issue https://github.com/facebook/react-native/issues/28140 .
This change sets the default for this property to `NO`, making the behavior consistent across iOS versions, and allowing developers full control.
## 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] [Changed] - ScrollView scrollIndicatorInsets to not automatically add safe area on iOS13+
Pull Request resolved: https://github.com/facebook/react-native/pull/29809
Test Plan:
Updated the RNTester example to explain what to expect. Also removed the `pageScreen` modal example for now as mentioned in my Github comment.
{F628636466}
Here are screenshots of the demo app (from the original bug) before (with safe area applied to insets) & after (without safe area applied to insets):
Reviewed By: p-sun
Differential Revision: D28229603
Pulled By: lunaleaps
fbshipit-source-id: 2e774ae150b1dc41680b8b7886c7ceac8808136a
Summary:
A CellRenderMask helps track regions of cells/spacers to render. It's API allows adding ranges of cells, where its otput be an ordered list of contiguous spacer/non-spacer ranges.
The implementation keeps this region list internally, splitting or merging regions when cells are added. This output will be used by the render function of a refactored VirtualizedList.
## 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] [Added] - Add "CellRenderMask" Region Tracking Structure
Pull Request resolved: https://github.com/facebook/react-native/pull/31420
Test Plan: Validated via UTs.
Reviewed By: lunaleaps
Differential Revision: D28293161
Pulled By: rozele
fbshipit-source-id: a5e4e2144a90387aabe0974650429018440abf67
Summary:
Changes the `ImageURISource` Flow type into an interface.
- This enables both objects and class instances to be subtypes of `ImageURISource`.
- This makes it invalid to spread `ImageURISource` as a type, so `interface X extends ImageURISource` can instead be used.
- This makes it invalid to spread `ImageURISource` as a value, so `getImageSourceProperties(x)` can instead be used.
- This makes it invalid to use `$Exact` with `ImageURISource`.
Changelog:
[General][Changed] - `ImageURISource` Flow type is now an interface instead of an object.
Reviewed By: timrc
Differential Revision: D29323508
fbshipit-source-id: 647c2f9b0bfead6d7e56bdb7108e623cbf8b6c89
Summary:
This was causing an upload error in FB Dating, will need to re-land with the fix.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D29320144
fbshipit-source-id: 5d09dd2171b5696afe89cffa064947f0a0bb413d
Summary: Changelog: [Internal] - Animated.event from my limited understanding attaches Animated.Values to native views. In terms of animation, Animated.Values are already handled by AnimatedMock to skip interpolation.
Reviewed By: GijsWeterings
Differential Revision: D29241590
fbshipit-source-id: 98650883dad53d6f77dbc398ba0cac903194deca
Summary:
This diff refactors the Image component in order to log the component hierarchy stacktraces for images rendering non-fb sources
changelog: [internal] internal
Reviewed By: yungsters
Differential Revision: D29266451
fbshipit-source-id: 826230b1a18a5809b340ef0767d80a281e20477a
Summary:
This diff adds logging to uncover what are the ReactNative screens that are rendering images using NON-Facebook domains
changelog: [internal] internal
Reviewed By: yungsters
Differential Revision: D29179990
fbshipit-source-id: 85f6380848d1ac1461419bc29c4666be389fb87a
Summary:
Changes `ImageURISource` back to an object type.
It was changed to an interface by D27193522 (05418f8fcc), but that is not the right direction for this type.
Changelog:
[Internal] - There was no changelog entry for this initially, so the revert can also be omitted.
Reviewed By: lunaleaps
Differential Revision: D29205798
fbshipit-source-id: 727ef70bbf47d14b163ecf5d6f31184da51c894a
Summary:
## Context
In dev mode, Metro hijacks the JavaScript `console`, and prints all logs into the terminal running the Metro server.
## Problem
We have no way to distinguish between Bridge mode and Bridgeless mode logs. This makes it hard to tell catch warnings and errors are coming from bridgeless mode.
## Changes
- This diff adds a "NOBRIDGE" prefix to all React Native Metro logs coming from Bridgeless mode.
- Bridge mode console logs/warnings/errors are **unaffected**.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D29152292
fbshipit-source-id: 257b8140327cfd7a0a10aa229bcb88117231e452
Summary:
In D28630805 (f78526ce3d) ([github link](https://github.com/facebook/react-native/pull/31457)) I added a setter to workaround a bug I perceived with `moduleRegistry`. Turns out - the proper fix was to remove the `synthesize` line. See conversation on linked diff for more context.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D29144717
fbshipit-source-id: aa95b670b540b9007eed76769c9babc10ea399ce
Summary:
Fixes https://github.com/facebook/react-native/issues/27099
When you upload a local file using XHR + the `FormData` API, RN uses `RCTNetworkTask` to retrieve the image file data from the local filesystem (request URL is a file:// URL) ([code pointer](https://github.com/facebook/react-native/blob/master/Libraries/Network/RCTNetworking.mm#L398)). As a result, if you are uploading a local image file that is in the app's directory `RCTNetworkTask` will end up using `RCTLocalAssetImageLoader` to load the image, which reads the image into a `UIImage` and then re-encodes it using `UIImageJPEGRepresentation` with a compression quality of 1.0, which is the higest ([code pointer](4c5182c1cc/Libraries/Image/RCTImageLoader.mm (L1114))). Not only is this unnecessary, it ends up inflating the size of the jpg if it had been previously compressed to a lower quality.
With this PR, this issue is fixed by forcing the `RCTFileRequestHandler` to be used when retrieving local files for upload, regardless of whether they are images or not. As a result, any file to be uploaded gets read into `NSData` which is the format needed when appending to the multipart body.
I considered fixing this by modifying the behavior of how the handlers were chosen, but this felt like a safer fix since it will be scoped to just uploads and wont affect image fetching.
## Changelog
[iOS] [Fixed] - Avoid re-encoding images when uploading local files
Pull Request resolved: https://github.com/facebook/react-native/pull/31457
Test Plan:
The repro for this is a bit troublesome, especially because this issue doesn't repro in RNTester. There is [some code](https://github.com/facebook/react-native/blob/master/packages/rn-tester/RNTester/AppDelegate.mm#L220) that is to be overriding the handlers that will be used, excluding the `RCTImageLoader`. I had to repro this in a fresh new RN app.
1. Create a blank RN app
2. Put an image in the folder of the app's install location. This would be similar to where files might be placed after an app downloads or captures an image.
3. Set up a quick express server that accepts multipart form uploads and stores the files
4. Trigger an upload via react native
```
const data = new FormData();
data.append('image', {
uri:
'/Users/arthur.lee/Library/Developer/CoreSimulator/Devices/46CDD981 (d0c8cb12f2)-9164-4925-9025-1A76C0D9 (1946aee3d9)F0F5/data/Containers/Bundle/Application/B1E8A764-6221-4EA9-BE9A-2CB1699FD218 (1c92b1cff6)/test.app/test.bundle/compressed.jpg',
type: 'image/jpeg',
name: 'image.jpeg',
});
fetch(`http://localhost:3000/upload`, {
method: 'POST',
headers: {'Content-Type': 'multipart/form-data'},
body: data,
}).then(console.log);
```
5. Trigger the upload with and without this patch
Original file:
```
$ ls -lh
total 448
-rw-r--r-- 1 arthur.lee staff 223K Apr 29 17:08 compressed.jpg
```
Uploaded file (with and without patch):
```
$ ls -lh
total 1624
-rw-r--r--@ 1 arthur.lee staff 584K Apr 29 17:11 image-nopatch.jpeg
-rw-r--r--@ 1 arthur.lee staff 223K Apr 29 17:20 image-withpatch.jpeg
```
Would appreciate pointers on whether this needs to be tested more extensively
Reviewed By: yungsters
Differential Revision: D28630805
Pulled By: PeteTheHeat
fbshipit-source-id: 606a6091fa3e817966548c5eb84b19cb8b9abb1c
Summary:
If function name is an empty string then it would fail to parse the line. And not only that, it would cause the entire stack to be lost. This fixes the issue by replacing `.+?` with `.*?`.
For example this line fails to parse:
```
at global (:2:4)
```
Changelog:
[General][Fixed] - Fixed bug parsing hermes call stacks when the file name is empty
Reviewed By: yungsters
Differential Revision: D29063192
fbshipit-source-id: 604e457af51f852fe547e6424283631ae148897d
Summary:
Rewrites `ReactNativeStyleAttributes` so that it is statically defined.
This means it will no longer require a handful of modules that defines `prop-types` only to use their keys.
Functionally, this should be equivalent to what was there before.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D29019308
fbshipit-source-id: 47f85a8c7703a133c68c20c7f3e14e1026ce4ff2
Summary:
Simplifies the Flow type for `ReactNativeStyleAttributes`, an internal module.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D29019311
fbshipit-source-id: cf95dac4b8c2261812cc1d753255dfb905540759
Summary:
Deletes `StyleSheetValidation` because it is `prop-types` in disguise.
Changelog:
[General][Removed] - `StyleSheet.create` will no longer do DEV-time validation.
Reviewed By: TheSavior
Differential Revision: D29019310
fbshipit-source-id: bfe886d8dc09a1aa8dac4a73bfd62f481e3eb9e9
Summary:
Removes the unnecessary dependency from `DeprecatedTextInputPropTypes` on `Text`. Just use `DeprecatedTextPropTypes` directly.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D29017596
fbshipit-source-id: b816c2261bf473e02473d84984cfb3d5a63ec8c1
Summary:
Moves `ImagePropTypes` out of `Image.android.js` in preparation for some cleanup.
Changelog:
[Internal]
Reviewed By: TheSavior
Differential Revision: D29017076
fbshipit-source-id: e7d3d6533f69dc2c54e7c25e215648d7c7ff1840
Summary:
This pre-suppresses the 154 error diff ahead of its release, since it is large.
Changelog: [Internal]
Reviewed By: samwgoldman
Differential Revision: D29065246
fbshipit-source-id: f418041305a46df410dcbe3d9a4db81a61ac7014
Summary:
As title
Changelog:
[General][Changed] Update Image.[android|ios].js to use import from instead of require
Reviewed By: TheSavior, yungsters
Differential Revision: D29003824
fbshipit-source-id: 0f98c730b1bd9cb581d2fcf6f4c0e911bb8c24b5
Summary:
Changelog:
[Internal] - Replace `useImperativeHandle` usage with new `useMergeRef` which will keep both the forwarded and internal ref handle up to date (in case the instance ever changes). That being said, this change was not motivated in fear of a stale ref but more an intention to show that `useImperativeHandle`'s use case is more about creating a selective API and `useMergeRef` is better suited for publishing ref updates.
Reviewed By: yungsters
Differential Revision: D28950632
fbshipit-source-id: 594afda02693545aab77f24566180c338b58bb8b
Summary:
Allow you to harvest the `UIAccessibilityContrastHigh` trait from iOS to show accessible colors when high contrast mode is enabled.
```jsx
// usage
PlatformColorIOS({
light: '#eeeeee',
dark: '#333333',
highContrastLight: '#ffffff',
highContrastDark: '#000000',
});
// {
// "dynamic": {
// "light": "#eeeeee",
// "dark": "#333333",
// "highContrastLight": "#ffffff",
// "highContrastDark": "#000000",
// }
// }
```
This is how apple's own dynamic system colors work under the hood (https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/color/#dynamic-system-colors)
---
The react native docs mention that more keys may become available in the future, which this PR is adding:
> In the future, more keys might become available for different user preferences, like high contrast.
https://reactnative.dev/docs/dynamiccolorios
## 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] [Added] - High contrast dynamic color options for dark and light mode.
Pull Request resolved: https://github.com/facebook/react-native/pull/31651
Test Plan: Added unit tests for `normalizeColor` to pass the high contrast colors downstream to RCTConvert
Reviewed By: lunaleaps
Differential Revision: D28922536
Pulled By: p-sun
fbshipit-source-id: f81417f003c3adefac50e994e62b9be14ffa91a1
Summary:
This PR aims to enable support for foreground ripple in Pressable. This makes it possible to show ripple on top of custom child components like Image as shown in the below example.
## 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] [Added] - Support for foreground ripple in Pressable
Pull Request resolved: https://github.com/facebook/react-native/pull/31632
Test Plan:
- Pass property useForeground: true in android_ripple config to verify the changes.
https://user-images.githubusercontent.com/23293248/120111371-4cecbf00-c18f-11eb-8acb-d10718d5483c.mov
Reviewed By: kacieb
Differential Revision: D28926493
Pulled By: yungsters
fbshipit-source-id: 12a6ba71a7dc6ed60fbaeb651f015cace38e03b1
Summary:
Creates a `useAnimatedProps` hook that is compatible with concurrent mode, and uses this in `createAnimatedComponent_EXPERIMENTAL`.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D28390393
fbshipit-source-id: d8aa471507a5d096832b93caf63a24f71733deda
Summary:
Creates `useRefEffect` which will be used by components in React Native.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D28862440
fbshipit-source-id: 50e0099c1a3e0a0f506bf82e68984fc5a032f101
Summary:
Creates `useMergeRefs` which will be used by components in React Native.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D28862439
fbshipit-source-id: 60eac7bcd6cceb06ee82181386b4712d642f5404
Summary:
Remove `defaultProps` from `Picker` of components, replace it with destructuring assignment.
## 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
-->
[JavaScript] [Changed] - Remove defaultProps from picker
close https://github.com/facebook/react-native/issues/31603
Pull Request resolved: https://github.com/facebook/react-native/pull/31644
Test Plan: all test suite and CI passes.
Reviewed By: TheSavior
Differential Revision: D28886320
Pulled By: lunaleaps
fbshipit-source-id: d88a922dffeebe2bce019250d460b5e43a0af562
Summary:
When maxLength is defined in <TextInput>, if the last character at max length is an emoji, the content of the input is cleared:
{F620865178} {F620865237}
Related Github issues:
https://github.com/facebook/react-native/issues/10929https://github.com/facebook/react-native/issues/10964
## Root cause:
When NSString was created, unicode characters were 16-bit long, so Objective-C considers every unicode character as 16-bit. However, unicode was later extended to more than 16bit, for example, emojis, which causes NSString substring method cuts off at the wrong position.
Example:
```
NSString *s = @"abc{emoji:1f601}";
NSInteger len = s.length; //length is 5 (as {emoji:1f601} occupies two 16-bit characters)
NSString *s3 = [s substringToIndex: 3]; //s3 is "abc"
NSString *s4 = [s substringToIndex: 4]; //s4 is null!
```
If string s, "abc{emoji:1f601}", is entered in <TextInput>, which has max length 4, it will truncate the string to the first 4 characters, "cutting" the emoji in half which causes encoding error and returns null. The text input is cleared.
## Solution:
If the character at max length is longer than 16-bit, truncate the character BEFORE it instead. In the previous example, truncate till index 3 instead of 4. The end result will be "abc" and the emoji is dropped.
## Changelog:
[iOS] [Fixed] - <TextInput> content is reset when emoji is entered at the max length
Reviewed By: p-sun
Differential Revision: D28821909
fbshipit-source-id: 4720d864970b554160ed5388f65b352ce95a6199
Summary:
The RN OSS release process includes manual testing that a new template app can be started under various platforms, JS engines, etc. This should ideally be automated, to help reduce wasted engineer-time, and to allow reliably increasing release velocity.
`react-native-windows` does already have tests to create and build template projects across our matrix, but they do not do any runtime validation on the newly created app. Adding a `testID` to the new app screen header gives us something to search for in black-box testing to validate that the app started successfully. This should help catch cases where a sample project in repo has changes not reflected in a newly created template app.
## 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] [Added] - Add testID to NewAppScreen Header Component
Pull Request resolved: https://github.com/facebook/react-native/pull/31652
Test Plan: Did not manually validate the change, though did check that `ImageBackground` forwards props to `Image`, and that `Image` is aware of `testID` and will forward to the native component.
Reviewed By: kacieb
Differential Revision: D28907197
Pulled By: p-sun
fbshipit-source-id: db3974294afba25878383f1955cad37b69d95da3
Summary:
This fixes how ES modules are handled in Jest tests in the react-native codebase.
They caused some problems before because `import` statements weren't inlined as `require` calls were, so there were some errors in tests when migrating from CommonJS to ESM.
This changes the transform that Jest uses to inline import statements the same way, so we can migrate everything without issues in tests.
Changelog: [Internal]
Reviewed By: kacieb
Differential Revision: D28899692
fbshipit-source-id: 027690f57ca3b5613c261a1089c0635af76662b2
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:
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:
With the conclusion of D27944688 (925af8ddea), this backs out the experiment introduced via D27987619 (f598dd0ee3).
Changelog:
[Internal]
Reviewed By: kacieb
Differential Revision: D28799741
fbshipit-source-id: 607ee85db26326e13dd8ddb52f5aebb732e9a354
Summary:
As suggested by motiz88 on D28421692 (883e0d5752), 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:
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:
23d9bf1a24 looks like it accidently removed `localeIdentifier` from I18nManager.
## 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] [Fixed] - Re-added localeIdentifier to I18nManager constants
Pull Request resolved: https://github.com/facebook/react-native/pull/31589
Reviewed By: GijsWeterings
Differential Revision: D28690202
Pulled By: fkgozali
fbshipit-source-id: 543a491f89789bca5629e1251c94fd055ec4a801
Summary:
This migrates all ObjC NativeModule setBridge: calls to the bridge compatible initialize: call. I filtered out ViewManagers.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D28595520
fbshipit-source-id: b0e5dd681fb3563894f1aa3da1728f0c694f04bb
Summary:
Accessibility service does not announce "selected" on accessibilityState = {selected: true} of the Button Component.
Issue link - https://github.com/facebook/react-native/issues/30956
## 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] [Added] - Add accessibilityState prop to Slider component
Pull Request resolved: https://github.com/facebook/react-native/pull/31145
Test Plan:
Verified accessibility states are read by voiceover and talkback. Some state values aren't handled by iOS and have been identified.
Added snapshot tests to test accessibilityState.disabled = disabled values
`js1 test Slider-test`
Reviewed By: yungsters
Differential Revision: D28337723
Pulled By: lunaleaps
fbshipit-source-id: 72a54d8d9dcf1fafb9785c81da99f32a21f3df00
Summary:
Changes `ExceptionsManager` in React Native so that errors with a `type` property equal to `'warn'` are not reported.
This change is banking on the fact that `type` is a non-standard and uncommon property on `Error` instances. If this ends up being problematic, we can instead change this to use a `unstable_type` or `unstable_level` property instead.
Changelog:
[General][Changed] - ExceptionsManager will no longer report exceptions with `type === 'warn'`.
Reviewed By: motiz88
Differential Revision: D28421692
fbshipit-source-id: 3ca19e29f32c8c5cad6dac637dcb930944fb24ed
Summary:
Pull Request resolved: https://github.com/facebook/react-native/pull/31543
Changelog:
[iOS][Added] - Description
When compiling iOS apps with flag `-Wnullability-completeness` (like Lightspeed app and soon Instagram), Objective-C headers are required to either have full *explicit* nullability annotations on all members of its public API, or none at all; partially annotated headers will fail to build that module.
RN native modules are currently generated with *partial* annotations. This works today because most apps are not compiled with `-Wnullability-completeness` turned on. But when we flip the switch for Instagram, the app doesn't build due to importing these RN partially annotated modules.
JavsScript Flow types are implied nonnull, and the current RN codegen translates Flow's [maybe/optional](https://flow.org/en/docs/types/maybe/) type to Obj-C `_Nullable` annotation, and everything else without an explicit Obj-C annotation. However this creates a mismatch with the Obj-C type system, where the implied default is *unannotated*, which is handled differently from nonnull when built with the nullability compiler flags.
There is a simple Obj-C macro that automatically adds *explicit nonnull* annotations to all members in a header: `NS_ASSUME_NONNULL_BEGIN` / `NS_ASSUME_NONNULL_END`. If we add this to *all* RN-generated headers, however, we run into issues:
1) We may erroneously assume any previously-unannotated header was meant to be nonnull and cause future bugs
2) Another compiler flag (`-Wnullable-to-nonnull-conversion`) statically analyzes Obj-C implementation code to prevent us from ever passing null to one of these headers. Much existing Obj-C code will break here, and it's ambiguous if these are true or false positives because of the first point.
Instead, in this diff we add a new BUCK flag `ios_assume_nonnull` to let module authors opt into automatic nonnull for unannotated members so that Obj-C headers are generated correctly in alignment with Flow's type system. We can migrate all libraries individually as needed and eventually make this the RN native codegen default.
Reviewed By: RSNara
Differential Revision: D28396446
fbshipit-source-id: ad3a3a97ab19183df4ef504b1c3140596c8f69ca
Summary:
Cleans up the `ExtendedError` internal type and moves it into a separate module instead of burying it in `parseErrorStack.js`.
Also, this resolves some unnecessary Flow type suppressions.
Changelog:
[Internal]
Reviewed By: GijsWeterings
Differential Revision: D28470299
fbshipit-source-id: 04093243f06f67f41567270ef9778f01c7549b05
Summary:
Cleans up `reactConsoleErrorHandler` in `ExceptionsManager` using modern language features, and fixes a minor edge case with how warning-like errors are handled.
Changelog:
[General][Fixed] - Avoid downgrading `console.error` when passed warning-like objects.
Reviewed By: GijsWeterings
Differential Revision: D28418488
fbshipit-source-id: 394e8608c2c81c794c9a0fc155142dcfcfe1c661
Summary:
Minor cleanup of `ReactFiberErrorDialog` with no behavior changes.
Changelog:
[Internal]
Reviewed By: GijsWeterings
Differential Revision: D28423265
fbshipit-source-id: 796777ca2c26d6d7cfae956299786151c74e937f
Summary:
Fixes https://github.com/facebook/react-native/issues/28517
Animated.loop needs to reset the animation after each iteration but currently, natively driven animations are not getting reset properly.
## 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] [Fixed] - Fix natively driven animations not getting reset properly
Pull Request resolved: https://github.com/facebook/react-native/pull/29585
Test Plan: Tested within RNTester
Reviewed By: kacieb
Differential Revision: D28383538
Pulled By: yungsters
fbshipit-source-id: 40790ad8f825c402afc3515ef6afc00570704109
Summary:
This check will never pass because `this._propsAnimated` contains an instance of `AnimatedProps`, but `nextProps` contains an object literal containing the new props.
Changelog:
[Internal]
Reviewed By: JoshuaGross, TheSavior, kacieb
Differential Revision: D28271627
fbshipit-source-id: c563eec1eeaee5eb84bb01525313b46db502225a
Summary:
Decouples `__attach` from the constructor in `AnimatedProps`.
This change will enable the instantiation of `AnimatedProps` (and subsequent invocation of `__getValue()`) without having to trigger side effects until after mount or update. This is important in order for `Animated` to ever become safe for Concurrent Mode.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D28271628
fbshipit-source-id: 6ccfed6de79382cecdfa6939c7dad3134e1ecaaa
Summary:
Having to import `useContext` every time is annoying, so this just creates a convenience function to get it.
Changelog: [Internal]
Reviewed By: GijsWeterings
Differential Revision: D28258305
fbshipit-source-id: 7293478f9baa11711a541f987225108871688e0e
Summary:
I added onPressIn & onPressOut props to Text to help implement custom highlighting logic (e.g. when clicking on a Text segment). Since TouchableOpacity can't be nested in Text having custom lineHeights without bugs in some occasions, this modification helps to replicate its behavior.
## Changelog
[General] [Added] - Add onPressIn & onPressOut props to Text
Pull Request resolved: https://github.com/facebook/react-native/pull/31288
Test Plan:
```
const [pressing, setPressing] = useState(false);
<Text
onPressIn={() => setPressing(true)}
onPressOut={() => setPressing(false)}
style={{ opacity: pressing ? 0.5 : 1 }}
/>
```
Thanks in advance!
Reviewed By: yungsters
Differential Revision: D27945133
Pulled By: appden
fbshipit-source-id: 8342ca5f75986b4644a193d2f71eab3bc0ef1a5f
Summary:
Changelog:
[General][Changed] Refactor ScrollViewStickyHeader to a functional component to remove unsafe lifecycles and mutations during render
Reviewed By: lunaleaps
Differential Revision: D28203776
fbshipit-source-id: 615c8e1cd9e9e26d25c7d02aee7e4a0bfc8ec6c3
Summary:
This diff deletes the registerGeneratedViewConfig API that is not used anymore.
This API was likely ONLY used internally at facebook, that's why I'm not deprecating it.
changelog: [Delete] Delete registerGeneratedViewConfig API
Reviewed By: fkgozali
Differential Revision: D28207558
fbshipit-source-id: 8598591e7ba1a7b001c87cb8728f2c599b1bbf63
Summary:
Some components are using `LogBoxData` directly, forcing logs to be shown on the screen even when LogBox is uninstalled. This changes all accesses to `LogBoxData` to go through `LogBox` so `uninstall` is used correctly.
It also changes when LogBox is installed, moving it from `AppContainer` to `InitializeCore` (which happens earlier) so we can capture more logs in LogBox.
Changelog: [General][Changed] Initialized LogBox earlier and centralized access in LogBox module
Reviewed By: rickhanlonii
Differential Revision: D27999361
fbshipit-source-id: 1115ef6b71e08cc33743d205da0064fbe9a74a0e
Summary:
Changelog:
[General][Added] Add support for "togglebutton" accessibilityRole
# Context
The role for ToggleButton, which is needed on Android to implement toggle buttons correctly, is not currently supported.
# What does this diff do?
Adds support for accessibilityRole `"togglebutton"`.
On Android, this maps to class `"Android.widget.ToggleButton"`.
iOS does not have an equivalent trait for togglebutton, so I set it to be the same as setting `accessibilityRole="button"` for iOS.
# Caveats - checked vs selected
It seems to me like this role currently requires that you set `accessibilityState={{checked: true/false}}`. The behavior is strange when setting `selected` state, I think because on Android ToggleButtons are meant to use `checked` to indicate toggled on/off.
This is tricky because typically on iOS if you have a toggle button, you would use `selected` instead of `checked`, so RN users are likely to mess this up.
Possible solutions:
1. document that you should use `checked` state on Android for toggle buttons (and maybe throw a warning if someone passes in `selected`).
2. have RN ignore it if someone passes in accessibilityState `selected`, if this role is used.
3. Have RN convert passed in `selected` state to `checked` on the Android side.
Reviewed By: nadiia
Differential Revision: D27976046
fbshipit-source-id: 4ce202449cf2371f4bf83c4db2d53120369ee7b0
Summary: Changelog: [Fabric][iOS][Fix] Remove use of bridge from Modal by dismissing Modal with visible prop
Reviewed By: sammy-SC
Differential Revision: D28074326
fbshipit-source-id: 0278bfb031db802b59429c553ac62d83838f4cc9
Summary:
Changelog: [Internal]
Static ViewConfigs are not yet available in Fabric. ViewConfigs are generated from Paper view managers.
For a prop to pass through from JS to iOS, props in [RCTModalHostViewNativeComponent.js](dc80b2dcb5/Libraries/Modal/RCTModalHostViewNativeComponent.js) need to match RCT_EXPORT_VIEW_PROPERTY in RCTModalHostViewManager.m.
Reviewed By: sammy-SC
Differential Revision: D27977574
fbshipit-source-id: 9790d93500890a04ffc0fb4d2bcd2de5187f1fc0
Summary:
This diff migrates RCTMultilineTextInputNativeComponent to use NativeComponentRegistry instead of requireNativeComponent. The intention is to unify the way the component is registered and enable StaticViewConfigs for this component
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D28116333
fbshipit-source-id: b245026ebcd564380d0c74bbd6d9a36c661a8e71
Summary:
This diff migrates RCTSingelineTextInputNativeComponent to use NativeComponentRegistry instead of requireNativeComponent. The intention is to unify the way the component is registered and enable StaticViewConfigs for this component
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D28116332
fbshipit-source-id: d0a1a512a1cd967608512423db3dffa7c68fd2c5
Summary:
This diff reports warning when a method of the LazyUIManager is called when using fabric and StaticViewConfigs enabled
changelog: [Android][changed] Deprecate UIManager methods when using the new architecture enabled
Reviewed By: fkgozali
Differential Revision: D28108804
fbshipit-source-id: 4b430bdefa67914883a595dff97ea6c9ffd93361
Summary:
NativeAnimationModule on Android is using batches to combine related updates together. In Fabric, this process is controlled by JS, which schedules starts batching when Animated component props are about to be updated.
In rare cases when there's no prop update (like calls to `setValue` on `AnimatedValue`), changes weren't applied until the next batch was scheduled. This change ensures that such changes get applied directly.
This problem doesn't happen on iOS or non-Fabric surfaces, because they use per-frame scheduling instead.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D28100641
fbshipit-source-id: 87b3acb3a8de131cdcb2104dc121d40eccfbc29d
Summary:
In development, we can specify a debug name to force the whole React tree to have a meaningful name. This is useful for debugging: React DevTools, component stack traces, etc. More context in D26637787 (eeb36f4709).
This worked fine until now because `renderApplication` is never called more than once per React Native root. With pre-rendering, this won't be true as we'll be able to re-render the whole React tree with new props (after navigating to the screen).
The problem with the current implementation is that we generate a new component every time `renderApplication` is called, which makes the React reconciliation consider them different components and discards the whole sub-tree.
This fixes it by caching those components so we always return a component with the same identity (exactly the same function) when we call `renderApplication` repeatedly.
This won't have any effect in production where these components aren't created at all.
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D28061384
fbshipit-source-id: 95833a5b74bb622896cb47426f74324d8740e5d7
Summary:
Runs an A:A react sync against the current revision to pick up the updates from the sync script.
Changelog: [Internal]
Reviewed By: yungsters, kacieb
Differential Revision: D28103715
fbshipit-source-id: 3593909e999bdceeb95423dc37dc0ee4282963d9
Summary:
Changelog:
[General] - Reflect Hermes release version from HermesBadge
It was a common footgun that an unexpected version of Hermes
engine is used in a RN app. To help with indicating this from
the runtime, Hermes exposes its OSS release version from
`HermesInternal.getRuntimeProperties()` Starting from 0.8.0.
This diff updates the `HermesBadge` used by `NewAppScreen`
header to reflect the version.
Reviewed By: nadiia
Differential Revision: D24436609
fbshipit-source-id: 8ba45be598a7d5af0e38f5044f9370fc7e1eb9a1
Summary:
Updating the regex to avoid a potential regular expression denial-of-service vulnerability.
Changelog: Update validateBaseUrl to use a more robust regular expression. Fixes CVE-2020-1920, GHSL-2020-293
Reviewed By: lunaleaps
Differential Revision: D25507604
fbshipit-source-id: c36a03c456881bc655c861e1a2c5cd41a7127c9d
Summary:
This fixes an error where folly fails to build on Xcode 12.5, by bumping the various folly deps in RN to builds with a fix.
Next step is to commit this to 0.64 release branch
allow-large-files
Changelog: [iOS] Fix builds on Xcode 12.5
Reviewed By: fkgozali
Differential Revision: D28071808
fbshipit-source-id: 236b66bf8294db0c76ff25b11632c1bf89525921
Summary:
This diff ships the virtualizedlist remeasure fix implemented in D27003249 (1bc06f18c6)
For more details about experiment see: https://fb.workplace.com/groups/rn.engineering/permalink/2831770330485832/
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D28072308
fbshipit-source-id: c23c958ca9f2991236cb5a5c02084722aa6de919
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
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
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
Summary:
This change caused crashes in animations on some surfaces.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D28013969
fbshipit-source-id: 95845c69d6e67d59582ea14ad08cbf42fd3e2f8f
Summary:
Changelog:
[General][Changed] Make the RootTag an opaque type
Reviewed By: yungsters
Differential Revision: D27992320
fbshipit-source-id: 2901f0e59f573106295b986fe04db227134235da
Summary:
Changelog:
[General][Changed] Convert require statements to use import from in Libraries/Components
Reviewed By: lunaleaps
Differential Revision: D27921557
fbshipit-source-id: 3f1618455a47a56c4a090f3ececfef88476c0b8a
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
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
Summary:
D27682424 (ea1ff374de) updated how animated node batches are executed in Fabric. On Paper, these batches were controlled by native module in some places (batch was executed ~every 2 frames), but some animations were switching animation batching control to JS globally there as well.
This change updates two things:
- If batching is controlled by native, it makes sure batches are calculated correctly.
- At the same time, this change switches control for animation node batching to JS, aligning it with Fabric.
Changelog: [Internal]
Reviewed By: JoshuaGross, mdvacca
Differential Revision: D27939659
fbshipit-source-id: d6251bce2a303a4a007dc10297edc0175cc4b348
Summary:
## Context
Trying to fix this js error
```
com.facebook.errorreporting.lacrima.common.exception.LacrimaJavascriptException: Error: Module RCTEventEmitter has not been registered as callable. Did you forget to call `RN$registerCallableModule`?, js build: UNKNOWN
```
https://fburl.com/logview/fvc33d48
Changelog:
[General][Changed] - Register RCTEventEmitter as callable module for Venice
Reviewed By: PeteTheHeat
Differential Revision: D27969226
fbshipit-source-id: 8e807ee5b2ef447b0bb49fa2107352d89584c181
Summary:
Adding support for DatePickerStyles on iOS13.4+
Changelog:
[iOS][Added] - Expose UIDatePickerStyles as a prop for DatePickerIOS
Reviewed By: PeteTheHeat
Differential Revision: D27953279
fbshipit-source-id: a35adf245147467ecbacac3770b9c50836cea468
Summary:
Adding support for DatePickerStyles on iOS13.4+
Changelog:
[iOS][Added] - Expose UIDatePickerStyles as a prop for DatePickerIOS
Reviewed By: PeteTheHeat
Differential Revision: D27948608
fbshipit-source-id: fcc16c630148818d9db0c9eef8363f8592b13791
Summary:
This diff flips the order of the tuple returned by useTransition.
See here for more info: https://github.com/facebook/react/pull/20976
Changelog: internal
Reviewed By: gaearon
Differential Revision: D27928490
fbshipit-source-id: a1896f92ef24382012fa3be1ef043752e62b21e7
Summary:
Check the existence of `addListener` and `removeListeners` in the native module passed to `NativeEventEmitter` to determine if it can be used.
Changelog: [General][Changed] Show warning when native module without `addListener` or `removeListeners` is passed to `NativeEventEmitter`
Reviewed By: yungsters
Differential Revision: D27851425
fbshipit-source-id: c0ad3ba65a9239f5bf84548dab36e8dfbc51058a
Summary:
Disable `accessibilityState` when the `TouchableWithoutFeedback` is `disabled`. This fixes https://github.com/facebook/react-native/issues/30953
## Changelog
[General] [Changed] - Disable `accessibilityState` when the `TouchableWithoutFeedback` is `disabled`.
Pull Request resolved: https://github.com/facebook/react-native/pull/31297
Test Plan: Tested the `TouchableWithoutFeedback` component on an Android device
Reviewed By: nadiia
Differential Revision: D27770689
Pulled By: kacieb
fbshipit-source-id: a317246021354ed288b093f8a5e6fbba43d3a04e
Summary:
CocoaPods will display a "fatal: not a git repository" when these podspecs are consumed within Facebook's internal Mercurial repository due to the reliance on `git` to obtain the current commit hash.
In these cases, the podspec is being consumed locally and the commit hash is unnecessary.
The error is removed by avoiding the use of `git` if the current working directory is not a git repository (or any of the parent directories).
Changelog:
[Internal] [iOS] - Remove CocoaPods error within Facebook's repository
Reviewed By: fkgozali
Differential Revision: D27750974
fbshipit-source-id: 99159611c580baf5526f116948c5ff60e1c02e5c
Summary:
This is a small cleanup to move initialization out of the `constructor` as it is unnecessary, and it is currently double initializing a few values.
Changelog:
[General][Changed] Clean up the initialization of instance variables in ScrollView
Reviewed By: nadiia
Differential Revision: D27631320
fbshipit-source-id: 762277e4993a9ce86d444ff2d9e845c93e94d1a8
Summary:
When the React Native Cmd+D menu is opened, something re-runs module initialization code (including DevTools backend initialization) which recreates the `WebSocket` and kills any already-connected frontend.
It's not clear to me why this is done. (Intentional? Accident?) But it makes it difficult to connect the React Native Inspector and DevTools together without multiple reloads. This Diff prevents the Cmd+D menu from killing the `WebSocket` connection as a workaround. A better long-term fix would (probably) be to not eagerly re-run these modules.
## Changelog
[General] [Fixed] - Don't disconnect DevTools WebSocket connection on Cmd+D
Reviewed By: fkgozali, sammy-SC
Differential Revision: D27742376
fbshipit-source-id: 60ab3e4763da6b055c28c7aafc6d460e7f4a601d
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:
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:
Cleans up some minor redundant internal types in `_EventEmitter.js`.
Changelog:
[Internal]
Reviewed By: rubennorte
Differential Revision: D27712301
fbshipit-source-id: e6affcb7948e0f47a1775b74b12f59ec2a6abddb
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:
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:
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:
## Context
In native modules implementing an event emitter, we can wait for JS to subscribe to an event before making the subscription to the right native API in the native module. This is only supported on iOS at the moment and we want to support it on Android too, so we can manage resources more efficiently and avoid custom code to do this on Android, like this:
https://www.internalfb.com/intern/diffusion/FBS/browse/master/xplat/js/RKJSModules/public/Dating/Profile/ProfileView/ProfileGemstoneProfileView.js?commit=165ad219e6bf&lines=302-304
The way this works now is by creating instances of `NativeEventEmitter`, where we pass a reference to the native module that needs to be notified when there are new subscriptions. We have explicit code to ignore this native modules in all platforms except for iOS:
https://www.internalfb.com/intern/diffusion/FBS/browsefile/master/xplat/js/react-native-github/Libraries/EventEmitter/NativeEventEmitter.js?commit=5a1e671453465e844dd851c458cb2467a2db5d03&lines=44-52
## Changes
This removes the check for iOS from `NativeEventEmitter` so we also try to use the native module to notify subscriptions on Android.
We have migrated all existing code passing a native module to `NativeEventEmtiter` to only pass it on iOS, so we don't change this behavior in existing code.
Any other existing code using this API is most likely fine too. It didn't work before so the expectation is that the native module wouldn't be implemented on Android anyway.
Changelog: [Android][Changed] - Modified `NativeEventEmitter` to also use the passed native module to report subscriptions on Android
Reviewed By: yungsters
Differential Revision: D27500994
fbshipit-source-id: ef82da04020fb08cd0ea4f1cfffd1da6453ab0b9
Summary:
This diff adds a new variable called "DisplayMode" into SurfaceHandler.cpp and FacebookAppRouteHandler.js. The purpose of DisplayMode is for the native pre-render system to notify React that the a surface is either being "pre-rendered" or "rendered"
When the surface is being "pre-rendered" (displayMode == "SUSPENDED"), react will create and commit React Trees, but it will not execute use-effect callbacks
When the surface is being "rendered" (displayMode == "VISIBLE"), react will create and commit React Trees and it will not execute all use-effect callbacks that weren't executed during "pre-rendering"
By default surfaces are going to be rendered with displayMode == "VISIBLE".
This diff should not create any change of behavior for now, this is the infra required to integrate the new offScreen API the react team is working on for pre-rendering system
changelog: [internal] internal
Reviewed By: yungsters
Differential Revision: D27614664
fbshipit-source-id: f1f42fdf174c2ffa74174feb1873f1d5d46e7a95
Summary:
This diff introduces the new function "setSurfaceProps" in SurfaceRegistry and AppRegistry
This new method will be used to update initialProps of a surface at the root level. In the near future this will be useful to integrate the OffScreen API component in pre-rendering
changelog: [internal] internal
Reviewed By: JoshuaGross
Differential Revision: D27607587
fbshipit-source-id: 3cc58c51924feb68f6a24bf762986c57f9a245ae
Summary:
We're making the getTurboModule: method required for all classes that conform to RCTTurboModule.
Many of our ObjC-only and Cxx NativeModules don't implement this method. This diff implements a getTurboModule: method on all those modules that returns nullptr.
**Question:** Why is it fine to make ObjC-only NativeModules return nullptr from their getTurboModule: method?
- Because they're only accessed from ObjC, and should appear as null on the JavaScript side. Longer term, these NativeModules will also go away.
**Question:** Why is it fine to make Cxx NativeModules return nullptr from getTurboModule: method?
- Because after D27316872, the TurboModuleManager checks if the module is a CxxModule first. If it is, we do an early return, and never call the module's getTurboModule: method.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D27316871
fbshipit-source-id: bc693f2927ab3b0de24e6e9e7699390ec0f7d729
Summary:
Changelog:
[Internal] - Update Switch to allow injected implementations
## General understanding of the component
The main flow of Switch is pretty straightforward, basically passing the props to the respective native component which uses the platform switch views on Android / iOS
The interesting parts of Switch is the fact that it's a controlled component -- meaning that this component sees the JS value prop as the source of truth about the state of this component and any time the native value of the switch is out of sync with the JS value prop, we send a command `setNativeValue` to keep those in sync.
The problems I ran into:
* Keeping native and JS in sync
* Switch skips animation occassionally on iOS simulator
## How we keep native and JS in sync
By construction, the native value of the component should be the same as JS value. Then, we know the native value has changed whenever the callback `handleChange` has been fired.
**Before**
In the handleChange callback, we'd set an [instance variable `lastNativeValue` with the updated value](https://fburl.com/diffusion/nangxzoh) and force update. Then, in `componentDidUpdate`, we'd send the native commands if we determine that `lastNativeValue` and the `value` prop were out of sync.
**After**
For our modern implementation, we store the value of the switch as reported by `handleChange` and check it against the `props.value` of the switch. If they are out of sync then we will update the native switch via the switch command.
**Why is `native` an object?**
We need to run the `useLayoutEffect` every time `handleChange` is called independent of the value of the switch.
**Why not move the logic of dispatching commands to `handleChange`?**?
This would change behavior from old implementation where we would call `onChange` handlers and then re-render. Additionally, the logic to run the native commands were on `componentDidUpdate` which would've run when any prop changed. We can simplify this down to caring only when `props.value` updates.
## Unsolved, existing issue: Switches skip animation occasionally
* This occurs both in the modern and old versions of Switch and I've only seen this on iOS simulators. It occurs most frequently in the "events" example where two switches' values are synced and most often the first transition after we navigate to the example surface. I have not been able to reproduce this behavior on device.
* Something must be triggering a re-render in the middle of native's animation..
{F564595576}
Reviewed By: nadiia, kacieb
Differential Revision: D27381306
fbshipit-source-id: 06d13c6fe1ff181443f4b8dd27fb1ac65e071962
Summary:
Unifies the platform-specific implementations of `AccessibilityInfo` to simplifying checking Flow types and making changes to the module.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D27578847
fbshipit-source-id: 84dc274a66acd22fc6f1dd2773a4e4630761e17d
Summary:
Removes `AccessibilityInfo.fetch` which had already been deprecated for a while by 0090ab32c2.
Changelog:
[General][Removed] - Removed `AccessibilityInfo.fetch`, use `isScreenReaderEnabled` instead.
Reviewed By: kacieb
Differential Revision: D27576528
fbshipit-source-id: f5df3445b4cc3bcb4ce6873c6845748109bc393d
Summary:
Refactors `AccessibilityInfo` so that it does not reimplement the event listener logic that is already implemented in `EventEmitter` (which backs the implementation of `RCTDeviceEventEmitter`).
This also means that calling `AccessibilityInfo.removeEventListener` will correctly display a deprecation error, due to `EventEmitter.removeListener` being deprecated. In a future release, both of these methods will be removed.
Changelog:
[General][Deprecated] - Deprecate `AccessibilityInfo.removeEventListener`.
Reviewed By: kacieb
Differential Revision: D27574340
fbshipit-source-id: 98c71d9c1470018df0f1526cc2f349aac842e786
Summary:
If an invalid color is supplied to a native component that expects `Array<ColorValue>`, it is currently possible to produce an array that contains null or undefined elements. This is problematic because the native component may not know what to do with the null or undefined value.
This changes `processColorArray` to always return an array with valid color values. Any invalid color values will fallback to being transparent black, `0x00000000`.
Changelog:
[General][Fixed] - For native components that accept color arrays, invalid elements will now fallback to transparent with a console error.
Reviewed By: JoshuaGross
Differential Revision: D27542291
fbshipit-source-id: efa5d130644b3aee68d2b9fad6fdb61af11a2966
Summary:
This PR aims to add test's for button.
Snapshot test for PR https://github.com/facebook/react-native/issues/31001 . This would make sure `accessibilityState` is properly set.
## 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] [Added] - Test's for button
Pull Request resolved: https://github.com/facebook/react-native/pull/31189
Test Plan:
`npm test` to run the test's.
Since the disabled prop of button has precedence over `accessibilityState.disabled` the test's will make sure it remains this way.
Reviewed By: kacieb
Differential Revision: D27473082
Pulled By: lunaleaps
fbshipit-source-id: 65d82620e8c245c2a8e29c3e9a8252d3a4275b09
Summary:
Since TouchableHighlight and TouchableOpacity are being exported using `forwardRef`, it's messing up jest's snapshots and some matchers.
This commit 4b935ae95f fixed this for components being mocked on [setup.js](https://github.com/facebook/react-native/blob/master/jest/setup.js). However, these Touchables aren't being mocked.
It resolves https://github.com/facebook/react-native/issues/27721
## Changelog
[General] [Added] - Add displayName to TouchableHighlight and TouchableOpacity
Pull Request resolved: https://github.com/facebook/react-native/pull/29531
Test Plan: Check the new snapshots.
Reviewed By: kacieb
Differential Revision: D27485269
Pulled By: yungsters
fbshipit-source-id: ba2082a4ae9f97ebe93ba92971d58c9195bdf26d
Summary:
Changelog:
[iOS][Added] - Adds an ability to retrieve the notifications authorization status from JavaScript side.
Differential Revision: D27426952
fbshipit-source-id: 84a1eae1ff8c8f9f7601c7479745002c21178850
Summary:
It looks like `ScrollView` still contains the remnant props for VR platform, which afaik has be discontinued a while ago (please correct me, if I'm wrong).
This PR removes `scrollBarThumbImage` prop marked as VR platform only prop from `ScrollView`.
## 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
-->
[VR] [Removed] - remove VR platform specific `scrollBarThumbImage` prop from `ScrollView`
Pull Request resolved: https://github.com/facebook/react-native/pull/31230
Test Plan: CI
Reviewed By: javache
Differential Revision: D27367267
Pulled By: PeteTheHeat
fbshipit-source-id: b76fdb0e03c443aaf87308162bf75f8683220918
Summary:
The import of DialogManagerAndroid in [Alert.js](https://fburl.com/diffusion/n57e4l50) causes "Unable to get iOS TurboModule for DialogManagerAndroid" log.
Don't call ` TurboModuleRegistry.get` on DialogManagerAndroid when the Platform is iOS.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D27376204
fbshipit-source-id: 948da5c162100ffe196d5e0a54dc8b85659239ae
Summary:
After installed a third party library I just got "Error: not implemented" without any other informations in the stack trace. Adding a more specific sentence within the error's message can be useful to understand what is going on.
## Changelog
[General] [CHANGED] - Added context to URL's error messages when the feature is not implemented
Pull Request resolved: https://github.com/facebook/react-native/pull/31237
Differential Revision: D27367109
Pulled By: PeteTheHeat
fbshipit-source-id: 87e8b3beef661e028d89098729bd242a57bb9a47
Summary:
There are a surprisingly large number of nil modules in both bridge and bridgeless. So far, features may silently fail if a module is nil.
We can't log with with console.error or console.warn because many tests will break even though modules aren't used in the test.
Differential Revision: D27285601
fbshipit-source-id: 1467100f2a4c48e97de5dd6e846c26981c14f099
Summary:
Changelog:
[Internal][Changed] - Remove keyExtractor from defaultProps as part of larger effort to remove defaultProps from VirtualizedList
[General][Changed] - Remove data as a prop for VirtualizedSectionList. In the reactnative.dev docs it mentions that sections is the equivalent for *SectionList: https://reactnative.dev/docs/sectionlist#sections
[General][Changed] - Change export type of VirtualizedSectionList and wrap component updates in act in test.
[Internal] - Remove FlowFixMe from VirtualizedSectionList
Reviewed By: kacieb
Differential Revision: D27271493
fbshipit-source-id: f83bdcce9c71c140c8a8fb6f0ecd9bb520fcb85b
Summary:
When there are multiple sticky headers, ScrollViewStickyHeader should push up the header above it when it gets to the top.
This behavior was accidentally changed in D21948830 (fa5d3fb6b8) when this component was fixed to work in Fabric.
This diff added a new variable `_shouldRecreateTranslateY`, which determines whether the `translateY` value should be recreated on render. `_shouldRecreateTranslateY` was not being set to true during `setNextHeaderY`, so the next header's Y value was never accounted for at render.
Changelog:
[General][Fixed] Fix ScrollViewStickyHeader to push up header above it
Reviewed By: lunaleaps
Differential Revision: D27277829
fbshipit-source-id: 83c9aacd454be178649bf8d060d1a5c750f4060f
Summary:
If Fabric is "installed"/enabled in the JS VM, only send LayoutAnimations configureNext to Fabric.
This will have no impact unless your app is running Fabric and non-Fabric side-by-side.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D27274016
fbshipit-source-id: 5d709e23968c2b65cc79d5611170fb70a9578953
Summary:
Flow is changing the behavior of object types to no longer be valid supertypes of classes. This replaces object types when they appear as supertypes of classes to be interfaces to avoid errors when this change rolls out.
Changelog: [Internal]
Reviewed By: pieterv
Differential Revision: D27193522
fbshipit-source-id: c3e3fca8a4cacd90770a95b773ff2c659774b9a6
Summary:
https://github.com/facebook/react-native/issues/30950
automatically set `disabled` to accessibilityState when TouchableHighlight is disabled
## 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] [Changed] - Set disabled accessibilityState when TouchableHighlight is disabled
Pull Request resolved: https://github.com/facebook/react-native/pull/31135
Test Plan: Tested on physical android device that pressing disabled TouchableHighlight announces "dim" when talkback is on
Reviewed By: yungsters, nadiia
Differential Revision: D27157207
Pulled By: kacieb
fbshipit-source-id: b8e24aad699c43cf02401b3ba39726a06b751995
Summary:
We have migrated most markerCancel calls to markerDrop. This diff removes the last bit (QPLBase API and bindings)
Changelog: [Internal]
Differential Revision: D26945891
fbshipit-source-id: 09b727809b316286930ced8533f9c79007350687
Summary:
On iOS, not all touch events have timestamp associated. Don't report telemetry events for those events.
Separately, we can try to ensure that all iOS events have timestamps associated but it's low-pri.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D27179814
fbshipit-source-id: ea2745df560bc4e9e6744bdf8f54269223adb209
Summary:
#Changelog:
[General][Changed] - Remove `data` as a prop for VirtualizedSectionList. In the reactnative.dev docs it mentions that `sections` is the equivalent for `*SectionList`: https://reactnative.dev/docs/sectionlist#sections
Reviewed By: nadiia
Differential Revision: D26992800
fbshipit-source-id: afcd027fca0cc8b4d7418e0c5543382bc8e2f56c
Summary:
Changelog:
[Internal][Changed] -Remove keyExtractor from defaultProps as part of larger effort to remove defaultProps from VirtualizedList
Reviewed By: nadiia
Differential Revision: D26969588
fbshipit-source-id: b00922a339cbe471fcbf560ab4abdd9e48eda1fc
Summary:
Changelog:
[Internal][Changed] -Remove updateCellsBatchingPeriod from defaultProps as part of larger effort to remove defaultProps from VirtualizedList
Reviewed By: nadiia
Differential Revision: D26969581
fbshipit-source-id: b1d1d18d575d9a6af2e68fe564d221849094f26b
Summary:
Changelog:
[Internal][Changed] -Remove windowSize from defaultProps as part of larger effort to remove defaultProps from VirtualizedList
Reviewed By: nadiia
Differential Revision: D26969589
fbshipit-source-id: da6215ee3876c8f186d59f91ef6fd94396366119
Summary:
Changelog:
[Internal][Changed] -Remove scrollEventThrottle from defaultProps as part of larger effort to remove defaultProps from VirtualizedList
Reviewed By: nadiia
Differential Revision: D26969580
fbshipit-source-id: 504e11493113c01d70e77b90f96c6506c179c060
Summary:
Changelog:
[Internal][Changed] -Remove onEndReachedThreshold from defaultProps as part of larger effort to remove defaultProps from VirtualizedList
Reviewed By: nadiia
Differential Revision: D26969584
fbshipit-source-id: 03968c5831587f9ed60dc52c55c55c0980f20cbd
Summary:
Changelog:
[Internal][Changed] -Remove maxToRenderPerBatch from defaultProps as part of larger effort to remove defaultProps from VirtualizedList
Reviewed By: nadiia
Differential Revision: D26969582
fbshipit-source-id: 64a07aae11f0403b01c01896b4f83565da6ecf43
Summary:
Changelog:
[General][Changed] - Change VirtualizeUtils to use ESM and change function signature on `computeWindowedRenderLimits` as part of larger effort to remove defaultProps from VirtualizedList
Reviewed By: nadiia
Differential Revision: D26969586
fbshipit-source-id: cd1961a2088d37543dbc9bca8c4a062cdb426a35
Summary:
Changelog:
[Internal][Changed] - Remove initialNumToRender from defaultProps as part of larger effort to remove defaultProps from VirtualizedList
Reviewed By: nadiia
Differential Revision: D26969585
fbshipit-source-id: 8674544c06b7b99eee693cc7508c9e4199232e98
Summary:
Changelog:
[Internal][Changed] - Remove horizontal from defaultProps as part of larger effort to remove defaultProps from VirtualizedList
Reviewed By: nadiia
Differential Revision: D26969583
fbshipit-source-id: c21ac15a220a68a58e32b78dcc37c053756b72cf
Summary:
Changelog:
[Internal][Changed] - Remove disableVirtualization from defaultProps as part of larger effort to remove defaultProps from VirtualizedList
Reviewed By: nadiia
Differential Revision: D26969587
fbshipit-source-id: 662fa620bc5b6b9a64c1906f62dae1f4b373a23b
Summary:
This diff forces a remeasure of the children of VirtualizedLists everytime the VirtualizedList is measured.
The goal is to ensure that nested VirtualizedList has the correct "scroll information" all the time, scroll information information is used by ViewabilityHelper.computeViewableItems method to determine if Items of the list are visible to the user.
This new code is controlled by the MC: rn_core:enable_virtualizedlist_remeasure_children_if_needed.
changelog: [internal] internal
// I used an internal changelog because this is under a MC
Reviewed By: lunaleaps
Differential Revision: D27003249
fbshipit-source-id: f9452ceb27683b0f595dd4bffdcced0ecf6bb0b5
Summary:
Issue # https://github.com/facebook/react-native/issues/30934 .When using a screen reader disabled buttons do not announce that they are disabled.
## Changelog
[Android] [Changed] - Passing accessibility state in button so it can announce disabled in talkback
Pull Request resolved: https://github.com/facebook/react-native/pull/31001
Test Plan:
I have added Button in Button Example with accessibiltyState prop that will announce button is disabled when testing with talkback.
## Ios test
I am unable to run ios project on my machine. RNTesterPods.xcworkspace gives workspace integrity error :/
Reviewed By: kacieb
Differential Revision: D26492483
Pulled By: lunaleaps
fbshipit-source-id: c4bbe8ca896b0d303976591c300ccac67a96ac73
Summary:
See https://github.com/react-native-community/discussions-and-proposals/pull/335 for extra context.
A VirtualizedList may have sticky headers, forwarded on to ScrollView. These sticky headers are exempt from virtualization once realized for the first time. This change documents the behavior of keeping sticky header cells realized after scrolling away.
This scenario performs the same behavior as creating an internal "realization window" for sticky headers with a single cell window size. Generalizing the concept of realization windows should be shaped to support the existing sticky header scenario.
## 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] [Added] - Add tests describing current sticky header realization behavior
Pull Request resolved: https://github.com/facebook/react-native/pull/31075
Reviewed By: lunaleaps
Differential Revision: D26767582
Pulled By: appden
fbshipit-source-id: 0d151bd6046fcb5384c646205aafa1ca7edf6c77
Summary:
Restore deprecated event listener removal methods in order to minimize breaking changes for the next release. The methods will work, but they will not report a warning via `console.error`.
Changelog:
[General][Added] - `EventEmitter.removeListener` now emits a deprecation notice.
[General][Added] - Restored `AppState.removeEventListener` with a deprecation notice.
[General][Added] - Restored `Keyboard.removeEventListener` with a deprecation notice.
[General][Added] - Restored `Linking.removeEventListener` with a deprecation notice.
Reviewed By: nadiia, kacieb
Differential Revision: D26589441
fbshipit-source-id: 7d89982a182cf2163136e157d4c1beee91c30393
Summary:
Changes `Dimensions.addEventListener` to return an `EventSubscription` object that has a `remove()` method on it.
In an upcoming commit, calling `Dimensions.removeEventListener` will lead to a deprecation warning.
Changelog:
[General][Change] - `Dimensions.addEventListener` now returns an `EventSubscription`.
Reviewed By: kacieb
Differential Revision: D26808827
fbshipit-source-id: 0cfdc65b83c177f60937c1aa3a4cf633592f73d7
Summary:
This NativeModule will now be type-safe, and TurboModule-compatible.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D26956332
fbshipit-source-id: 6651a003c70819934869dd6a8c664ef984d0efcb
Summary:
Add a stickyHeaderHiddenOnScroll option to keep the sticky header hidden during scrolling down, and only slide in when scrolling up
Changelog:
[General][Added] - Add a stickyHeaderHiddenOnScroll option to keep the sticky header hidden during scrolling down, and only slide in when scrolling up
Reviewed By: JoshuaGross
Differential Revision: D26900810
fbshipit-source-id: 6bfb1a4da07fff0763223d60836df187f9d95dd6
Summary:
This diff creates a new unstable method (unstable_hasComponent) to expose `global.__nativeComponentRegistry__hasComponent` into NativeComponentRegistry.js
changelog: [internal] internal
Reviewed By: yungsters
Differential Revision: D26716903
fbshipit-source-id: 52ff63b2779f41770b292cfc0b9022b1669d59fe
Summary:
This diff migrates AndroidDropdownPicker to use NativeComponentRegistry instead of requireNativeComponent. The intention is to unify the way the component is registered and enable StaticViewConfigs for this component
changelog: [internal] internal
Reviewed By: yungsters
Differential Revision: D26810196
fbshipit-source-id: 7be0396d49d9e1413d424ab1be035cbb6a211706
Summary:
This diff migrates AndroidDialogPicker to use NativeComponentRegistry instead of requireNativeComponent. The intention is to unify the way the component is registered and enable StaticViewConfigs for this component
changelog: [internal] internal
Reviewed By: yungsters
Differential Revision: D26799476
fbshipit-source-id: d6605f60cc083d1d22b4f0fc0a2f79881502b1b4
Summary:
This diff migrates RCTPicker to use NativeComponentRegistry instead of requireNativeComponent. The intention is to unify the way the component is registered and enable StaticViewConfigs for this component
changelog: [internal] internal
Reviewed By: yungsters
Differential Revision: D26799477
fbshipit-source-id: 2f5935e0a4796c7a76921762a087cf7823ebd62e
Summary:
Changelog: [internal]
Add missing implementation of caretHidden to multiline text input. This will work for both React Native Classic and New React Native Renderer.
Reviewed By: shergin
Differential Revision: D26818087
fbshipit-source-id: 3597604a6bd414a4a3b292d809d63a18efa8acb3
Summary:
Debugging with not having Metro console.log() working in Venice is inconvenient.
After PeteTheHeat's fixes in diff series D26624224 the ground issues should be gone, so I tried removing the guard for Android and it worked.
The only issue I found is that when connected to Hermes Debugger in Flipper it keeps refreshing (reloading?), I posted here https://fb.workplace.com/groups/2308952995990093/permalink/2899448643607189/, with this found, I think it's a good start to iterate on since there are no crashes and this would help us a lot on Venice debugging.
Changelog:
[Android][Changed] - Remove developer tool guard for android
Reviewed By: PeteTheHeat
Differential Revision: D26779418
fbshipit-source-id: 96bb18771e01a25f84f845833a4f71e70433ef2b
Summary:
Changes `Appearance.addChangeListener` to return an `EventSubscription` object that has a `remove()` method on it.
In an upcoming commit, calling `Appearance.removeChangeListener` will lead to a deprecation warning.
Changelog:
[General][Change] - `Appearance.addChangeListener` now returns an `EventSubscription`.
Reviewed By: kacieb
Differential Revision: D26696388
fbshipit-source-id: d0bdeffff3a2a366b3c11b6dc1417dfb2f1455c2
Summary:
# The bug
Sticky headers would not "stick" to the top of the ScrollView on initial render. On subsequent redners, all sticking would work correctly.
# Why the bug existed
This code to initialize the animated values used for sticky headers was in `UNSAFE_componentWillMount` prior to D26375818 (1641d46529). `UNSAFE_componentWillMount` is called before `render`.
In D26375818 (1641d46529), I moved the code into `componentDidMount`, which is called after `render`.
This caused a problem because code in `render` was relying on these initializations being done already.
# How I resolved the bug
To resolve this, I initialize these values in the constructor.
# Reference
Docs for React mount ordering: https://reactjs.org/docs/react-component.html#mounting
Changelog:
[General][Fixed] Fix sticky header not sticking on first render in ScrollView
Reviewed By: nadiia
Differential Revision: D26792003
fbshipit-source-id: c575e8cdd1d986ce3c38941d95d763e329e74874
Summary:
Changelog:
[General][Changed] Hide caret in the TextInput during test runs.
Reviewed By: lunaleaps
Differential Revision: D26728766
fbshipit-source-id: b75827f00b4d5c6243d93106093f97b40dc4b366
Summary:
`React.ElementRef<HostComponent<mixed>>` is an inexact object type, which can not be spread into an exact object type, as is happening here. This error is masked in types-first mode, but causes the instance type of this component to be `any`. In a future version of Flow, this issue will be fixed, so this change unblocks upgrading Flow.
This change is likely to cause code using `TextInput` refs to find errors which were missed before.
Changelog:
[General][Fixed] - Fixed Flow typing of TextInput refs
Reviewed By: yungsters
Differential Revision: D26733314
fbshipit-source-id: 8aa26ce5b49357b279f76dd1767a17a9fb4dd4f1
Summary:
For better cross-platform consistency, migrate usages of NDEBUG to REACT_NATIVE_DEBUG. See flags.h for explanation.
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D26695016
fbshipit-source-id: 63e6f6fc919076d94f04416f6821f21e0b3707a3
Summary:
This diff broke scrolling on Profile React Native surfaces. Please see the task for repro steps. Backing this out.
Changelog:
[General][Changed] - Back out "React Native sync for revisions c3e20f1...4d28eca"
build-break
overriding_review_checks_triggers_an_audit_and_retroactive_review
Oncall Short Name: fbandroid_sheriff
Reviewed By: JoshuaGross
Differential Revision: D26708096
fbshipit-source-id: 40f1e7473b8cc041073b2658d46f9500281da99e
Summary:
We recently fixed RTL scrolling in Fabric on iOS: D26608231 (e5921f7f38)
Turns out, the mechanism for RTL scrolling on Android is completely different. It requires that content be wrapped in a "directional content view", which is `View` in LTR and `AndroidHorizontalScrollContentView` in RTL, backed by `ReactHorizontalScrollContainerView.java`.
iOS doesn't require that and just uses View and some custom logic in ScrollView itself.
In the future it would be great to align the platforms, but for now, for backwards-compat with non-Fabric and so we don't have to tear apart ScrollView.js, we codegen the AndroidHorizontalScrollContentView so it exists in C++, register the component, and stop mapping it to View explicitly in C++.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D26659686
fbshipit-source-id: 3b9c646dbdb7fe9527d24d42bdc6acb1aca00945
Summary:
Changelog:
[General][Added] - Added `debugName` parameter to `renderApplication` to use as the display name for the React root tree
Reviewed By: rickhanlonii
Differential Revision: D26637787
fbshipit-source-id: 3ddc037573f4434101a9d3dcb5592a127193481c
Summary:
"The instance should not stick around after unmount..." - Tim Yung, 2021
I have a hypothesis that, if a component instance of an animated component sticks around after unmount, it could cause memory leaks due to references to Fabric ShadowNodes across the JSI (this would not impact non-Fabric... in theory).
Wild guess. If OOMs disappear then maybe this hypothesis is correct, but it's a long shot. I figure there's ~no harm in doing this cleanup here anyway.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D26650348
fbshipit-source-id: 90633db650b65755cacfb52344e7b53e46c9b125
Summary:
There's logic in Animated JS that prevents flattening of animated views in Fabric. However, we cannot actually detect Fabric vs non-Fabric in the first render pass; in the past we defaulted to assuming non-Fabric. Now we assume Fabric for View flattening purposes.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D26647393
fbshipit-source-id: c91b51aeeb4f352cc502bc018f086e36fd1ffd85
Summary:
This PR fixes few suppressed Flow issues in `VirtualizedList` component.
I have also removed few no longer valid Flow suppressions in `ActivityIndicator` and `ReactNativeTestTools`.
## Changelog
[General] [Fixed] - Flow: fix few issues in `VirtualizedList`,
[General] [Removed] - Flow: remove few no longer valid suppressions in `ReactNativeTestTools`
Pull Request resolved: https://github.com/facebook/react-native/pull/30128
Test Plan: Successful run of `yarn flow` check.
Reviewed By: kacieb
Differential Revision: D26489398
Pulled By: lunaleaps
fbshipit-source-id: db71d8bfeb3b6dc5a2738a73ac6644aef4a0311b
Summary:
Changelog: [Internal]
I'm trying to get Fast refresh working in bridgeless mode. I need the ` require('./setUpReactRefresh');` line to be executed to do so.
I'm not sure why this was commented out in the first place, it seems to be working fine in FBiOS/FB4A.
Reviewed By: p-sun
Differential Revision: D26289573
fbshipit-source-id: 6151f781c31e3aadaebfeb759d3eb776e8b525cc
Summary:
This diff removes `UNSAFE_componentWillReceiveProps` and adds the changes to `componentDidUpdate` instead.
Why use `componentDidUpdate`? When reading through the [React docs on removing UNSAFE_componentWillReceiveProps](https://reactjs.org/docs/react-component.html#unsafe_componentwillreceiveprops), it says:
> If you need to perform a side effect (for example, data fetching or an animation) in response to a change in props, use componentDidUpdate lifecycle instead.
The original usage of `UNSAFE_componentWillReceiveProps` updates the content inset when `props.contentInset` changes. However, we don't always want it to update if the content inset hasn't changed, as calling `setValue` will reset the animated value unnecessarily, and kill any current animations (which we don't want to do). [React Native doc on setValue for reference](https://reactnative.dev/docs/animatedvalue#setvalue).
Changelog:
[General] Use componentDidUpdate instead of UNSAFE_componentwillReceiveProps in ScrollView
Reviewed By: lunaleaps
Differential Revision: D26487276
fbshipit-source-id: 77419deacf5db676cd721b58f34932bd6ca2399f
Summary:
Simplifies `RCTDeviceEventEmitter` to simply be an `EventEmitter`.
The only thing special about it is that all native events are emitted on it and that `NativeEventEmitter` composes it.
Changelog:
[General][Removed] - Removed `RCTDeviceEventEmitter.sharedSubscribers`.
Reviewed By: RSNara
Differential Revision: D26163660
fbshipit-source-id: aedff8323d86947220fc293a74a19a3981fd875a
Summary:
Previously this branch of code only ran on Fabric+iOS. It is also needed for non-Fabric+Android in case `setLayoutAnimationEnabledExperimental` is not called on Android and an animation is queued up.
Changelog: [Internal]
Reviewed By: ShikaSD
Differential Revision: D26466482
fbshipit-source-id: 11c50bf94daa287a619f2b623785b60675eb6cf0
Summary:
The purpose of this diff is to move all of the ScrollResponder methods into ScrollView to delete ScrollResponder.Mixin.
NOTE: ScrollResponder.Mixin uses a variable named "state" but it does not use React state correctly. Instead of calling `setState()`, state is set using `this.state.item = 123` ([example](https://www.internalfb.com/intern/diffusion/FBS/browsefile/master/xplat/js/react-native-github/Libraries/Components/ScrollResponder.js?lines=315)). This means these are not actually React state - these are functionally just variables. In this stack, these "state" items from ScrollResponder are turned into regular internal variables.
Changelog:
[General][Removed] Moved ScrollResponder.Mixin methods into ScrollView to Remove ScrollResponder.js
Reviewed By: lunaleaps, nadiia
Differential Revision: D20715880
fbshipit-source-id: 99441434a6dc1c8ff3f435e7d6ec2840821e4e05
Summary:
Removing log in PaperUIManager since this is logging warn messages for "Text" components
changelog: [internal] internal
Differential Revision: D26315745
fbshipit-source-id: 8871148b0fc1791e1723962f1f2477cd5e0c562d
Summary:
Rewrites `NativeEventEmitter` to not extend `EventEmitter` and to compose `RCTDeviceEventEmitter` instead of (mis)using its exported `sharedSubscriber` property.
This makes it easier to reason about `NativeEventEmitter`. Also, the extraneous methods on `EventEmitter` are no longer inherited.
Changelog:
[General][Removed] - `NativeEventEmitter` no longer inherits from `EventEmitter`, so it no longer implements `removeListener` and `removeSubscription`. Instead, use the `remove()` method on the subscription object returned by `addListener`.
Reviewed By: rubennorte
Differential Revision: D26163562
fbshipit-source-id: c1aadb99bdefbaa36fece57ce74604e414f94d4d
Summary:
Simplifies `Keyboard` by removing redundant methods and changing `addEventListener` to return an `EventSubscription`.
Changelog:
[General][Changed] - `Keyboard.addListener` now returns an `EventSubscription` object.
[General][Removed] - Removed `Keyboard.removeListener`. Instead, use the `remove()` method on the object returned by `Keyboard.addListener`.
[General][Removed] - `Keyboard` no longer inherits from `NativeEventEmitter`, so it no longer implements `removeAllListeners`, and `removeSubscription`.
Reviewed By: milroc
Differential Revision: D26163536
fbshipit-source-id: b4bd91627cd027a13fcba269a253823913eb7589
Summary:
Tweaks LogBox so that if all stack frames are collapsed, start off without collapsing any of them.
It saves developers from one extra interaction to make the LogBox actually useful for errors where every frame is ignored.
Changelog:
[General][Changed] - LogBox will not initially collapse stack frames if every frame would be collapsed.
Differential Revision: D26266195
fbshipit-source-id: dcdbe0834da5fc3a0bf49fb7857de30dd7e4b8cb
Summary:
It is currently possible to activate a disabled Pressable with VoiceOver/TalkBack. This fixes this.
Changelog:
[General][Fixed] Fix disabled prop not disabling onPress for voice assistant
Reviewed By: blavalla
Differential Revision: D26225448
fbshipit-source-id: 67fa10f9e5c50143d986dc709a2fb639fdc3e718
Summary:
FabricUIManager does not support it, the declaration is not correct.
Changelog: [Internal] Fabric-specific internal change.
Created from Diffusion's 'Open in Editor' feature.
Differential Revision: D26241483
fbshipit-source-id: 8a894dc847bce9c196d8ac2e1601853e4fe03e1d
Summary:
Simplifies `AppState` by removing redundant methods and changing `addEventListener` to return an `EventSubscription`.
Changelog:
[General][Changed] - `AppState.addEventListener` now returns an `EventSubscription` object.
[General][Removed] - Removed `AppState.removeEventListener`. Instead, use the `remove()` method on the object returned by `AppState.addEventListener`.
[General][Removed] - `AppState` no longer inherits from `NativeEventEmitter`, so it no longer implements `addListener`, `removeAllListeners`, and `removeSubscription`.
Reviewed By: wtfil
Differential Revision: D26161343
fbshipit-source-id: b3cff76bf0f8f7d79cd954fdef551d0654c682ca
Summary:
Removes the checks in `RCTDeviceEventEmitter` that were initially added to migrate call sites to other modules when `NativeEventEmitter` was introduced.
This set of checks is problematic for a few reasons:
1. Does not cover many other events that have since been introduced, so the small list covered is arbitrary.
2. Prevents composition of `RCTDeviceEventEmitter` in the implementation of those modules.
3. Code bloat.
Changelog:
[General][Removed] - `RCTDeviceEventEmitter` no longer throws for `SttatusBar`, `Keyboard`, and `AppState` events. However, you are still recommended to use the more appropriate modules for listening to these events.
Reviewed By: lunaleaps
Differential Revision: D26163602
fbshipit-source-id: 316287bfdf2947fe85d022a3f83a205e89c432ba
Summary:
When NativeUIManager.getConstantsForViewManager throws an exception from native, we just swallow that exception and set null as the view config. Instead, we should log that an error occurred. This way, we can tell if the NativeModule sync method call returned undefined, or if the NativeModule sync method call thew an exception.
I'll take a look and see if we can add this logging higher up in the native stack, so that we can actually capture the stack information from this NativeModule sync method call failure.
Created from Diffusion's 'Open in Editor' feature.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D26227379
fbshipit-source-id: 02b516d247f82f873f059005e6a2cc6f2a64fdb5
Summary:
Deletes `Linking.removeEventListener` in favor of returning the `EventSubscription` returned by `NativeEventEmitter.addListener`.
Changelog:
[General][Added] - `Linking.addEventListener` now returns a subscription with a `remove()` method.
[General][Removed] - Removed `Linking.removeEventListener`. Instead, call `remove()` on the subscription returned by `Linking.addEventListener`.
Reviewed By: rubennorte, wtfil
Differential Revision: D26155896
fbshipit-source-id: 1176ec6eae1c0fff2d68acf5411a18da530b212a
Summary:
ES Modules implicitly enable strict mode. Adding the "use strict" directive is, therefore, not required.
This diff removes all "use strict" directives from ES modules.
Changelog:
[Internal]
Reviewed By: motiz88
Differential Revision: D26172715
fbshipit-source-id: 57957bcbb672c4c3e62b1db633cf425c1c9d6430
Summary:
Changes the to-be-legacy `_EventSubscription` and `_EmitterSubscription` classes to implement the event-agnostic `EventSubscription` interface.
This interface is valuable because it abstracts away the event definitions.
Changelog:
[Internal]
Reviewed By: lunaleaps
Differential Revision: D26155911
fbshipit-source-id: f94280976d4f9219f4780ac8fae0d5fbc1865386
Summary:
Simplifies the implementation of `DevSettings`. The fact that it uses `NativeEventEmitter` is an implementation detail and does not need to be exposed via inheritance.
This also enables more code to be removed from production builds (because the development implementation is now statically enclosed by `__DEV__`).
Changelog:
[General][Changed] - `DevSettings` no longer inherits from `NativeEventEmitter`
Reviewed By: RSNara
Differential Revision: D26140148
fbshipit-source-id: 99fa9d0c6ce8e365f89936aa12a4720f7a04b984
Summary:
Removes the `options` argument in the `NativeEventEmitter` constructor. It was only being used for an experimental flag that is no longer necessary.
Changelog:
[General][Removed] - Removed second optional argument of `NativeEventEmitter` constructor
Reviewed By: RSNara
Differential Revision: D26138239
fbshipit-source-id: 0481ce44f0464668e3a6e7ffaf079d17c87afd42
Summary:
This addesses a few issues I noticed while migrating my app to the new build-time codegen on iOS.
1. I noticed random failures because of codegen on iOS. This is mostly due to the fact the codegen output files are not specified in the xcode script. The only reason it works relatively fine currently is because the codegen output is inside the input files directory. This has the side effect of causing files to be regenerated every build, then causes all core modules to be recompiled which adds up a significant amount of time to rebuilds. To fix this I added the generated files to the script phase output and moved the FBReactNativeSpec dir outside of the codegen source (Libraries). I moved it to the React directory as this seemed to make sense and is where a lot of iOS files are as well as the core modules. Note this might require internal changes. This removes the circular dependency between our build phase input and output so consecutive builds can be cached properly.
2. Add `set -o pipefail` to the xcode script, this helped propagate errors properly to xcode because of the `| tee` pipe so it fails at the script phase and not later with a header not found error. Also add `2>&1` to pipe stderr to stdout so errors are also captured in the log file.
3. Add the `-l` flag to the bash invocation to help finding the yarn binary. With my setup yarn is added to the system PATH in my user .profile. Adding this file will cause bash to source the user environment which xcode scripts does not by default. I think this will help with most setups.
4. If yarn is not found the `command -v yarn` would make the script exit without any output because of the -e flag. I made a change to ignore the return code and check later if YARN_BINARY is set and have an explicit error message if not.
## Changelog
[iOS] [Fixed] - Make codegen more reliable on iOS
Pull Request resolved: https://github.com/facebook/react-native/pull/30792
Test Plan:
Tested various project states to make sure the build always succeeds in RN tester:
- Simulate fresh clone, remove all ignored files, install pods, build
- Build, delete FBReactNativeSpec generated files, build again
- Build, build again, make sure FBReactNativeSpec is cached and not rebuilt
- Make the script fail and check that xcode shows the script error logs properly
Note: Did not test fabric
Reviewed By: fkgozali
Differential Revision: D26104213
Pulled By: hramos
fbshipit-source-id: e18d9a0b9ada7c0c2e608d29ffe88087f04605b4
Summary:
See comments. On iOS in Fabric, LayoutAnimations is only conditionally enabled; whereas on Android it's always enabled. That means for code on iOS that relies on the onComplete callback, there might be bugs.
Ensure the callback is always called on iOS by racing a timer with the animation completion.
This will be deleted before Fabric "ships" fully.
Impact is minimal since this change is scoped to only run on iOS and under Fabric.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D26166237
fbshipit-source-id: 9a07a402845c379e1511f199eef3d3e249e1eb06
Summary:
Refactors `RCTNeworking.ios.js` so that event registration does not get passed along to `NativeNetworkingIOS`. Instead, we go straight to `RCTDeviceEventEmitter` (which is what `NativeEventEmitter` ultimately does when `nativeModule` is not supplied).
This optimization reduces overhead of making network requests, and it is made possible because `NativeNetworkingIOS` does not actually do any meaningful work when `startObserving` is invoked.
Changelog:
[iOS][Removed] - Removed event methods except `addListener` from `Networking`
Reviewed By: lunaleaps
Differential Revision: D26137965
fbshipit-source-id: b6e0288689459ddb8ecf8d34dce6250d3b0ecb59
Summary:
Changelog: [internal]
`[self _invalidatePlaceholderVisibility]` wasn't triggered in multiline text input in Fabric. Even in Paper it was triggered what to me seems like coincidence rather than intention (I might be wrong). This is more explicit, visibility of placeholder text needs to be re-evaluated every time placeholder text is changed.
Reviewed By: shergin
Differential Revision: D26172754
fbshipit-source-id: 3a767d333b79c266a3d70a96883b1289fff16750
Summary:
This is just cleanup. When I migrated components to `Pressability` instead of `Touchable`, I left `TOUCH_TARGET_DEBUG` alone to minimize moving pieces. But I had created `PressabilityDebug` as the eventual destination for this logic.
Now that `Text` is migrated away from `Touchable` (see D26106824 (f275514f27)), this cleans up the final internal reference to `Touchable`.
Changelog:
[General][Changed] - `Touchable.renderDebugView` now accepts `ColorValue` instead of `string | number`.
[General][Removed] - Removed `Touchable.TOUCH_TARGET_DEBUG` property.
Reviewed By: kacieb
Differential Revision: D26108570
fbshipit-source-id: 2694c9a9c29182ae04a77ba6c2e4406fcd5a277e
Summary:
`sendAccessibilityEvent_unstable` is a cross-platform, Fabric/non-Fabric replacement for previous APIs (which went through UIManager directly on Android, and a native module on iOS).
Changelog: [Added] sendAccessibilityEvent_unstable API in AccessibilityInfo and sendAccessibilityEvent in React renderer
Reviewed By: kacieb
Differential Revision: D25821052
fbshipit-source-id: 03f7a9878c95e8395f9102b3e596bfc9f03730e0
Summary:
Rewrites the `Text` component using modern best practices.
Notably, `Text` no longer depends on `Touchable` and now instead depends on `Pressability`.
Changelog:
[Internal]
Reviewed By: mdvacca
Differential Revision: D26106824
fbshipit-source-id: 0797e66075ae03c51dd5b4b3395b21ae92c39ba6
Summary:
This diff adds TextInput in the list of components that support static view configs
changelog: [internal]
Reviewed By: yungsters
Differential Revision: D26040854
fbshipit-source-id: d6b5d3a78ef4657acf3f2c4ebe527ad4ca40bcb5
Summary:
This diff removes the call to UIManager.getViewManagerConfig into the deprecatedPropType method when static view configs are enabled
This was necessary to avoid innecessary calls to UIManager.getViewManagerConfig and to avoid loading UIManagerModule classes when static view configs are enabled
changelog: [internal] internal
Reviewed By: fkgozali, yungsters
Differential Revision: D26040855
fbshipit-source-id: 82cad9f4abe9898e781fd989ebaa03497dad926b
Summary:
This diff refactors the StaticViewConfigsPaperUIManager to avoid loading NativeUIManager.
This is part of a experiment to prevent loading UIManagerModule class in native.
changelog: [internal]
Reviewed By: JoshuaGross
Differential Revision: D25630215
fbshipit-source-id: 40d6f3b36ad4c3377820b1dcf0bd949db063d899
Summary:
This diff changes the flow types of RefreshControl.size prop from 'int' to string'. For more context see previous diff of the stack.
This diff will be landed as soon as the native release containing D25933458 (65975dd28d) goes to production.
It's important to clarify that there are currently no usages of this prop in production
Changelog: [Android][Changed] - RefreshControl.size prop changed its type to string, the valid values are: 'default' and 'large'
Reviewed By: JoshuaGross
Differential Revision: D25933457
fbshipit-source-id: 2f34566f2f8a097e6d40f63c09ecb3ada2fd8409
Summary:
NativeModule schema targets will now take the form '{library_name}-codegen-modules-schema'.
NOTE: Will launch the necessary diffs to make the same refactor in our component codegen.
Changelog: [Internal]
Differential Revision: D25968071
fbshipit-source-id: 1d7c9f4679e4ae6c26c9a29a74fa7b7ea76460eb
Summary:
Since `RCTNetworking` overrides init, it requires main queue setup. Native module infra currently throw a yellowbox if a module forgets it.
This diff fixes that.
{F361182429}
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D25962402
fbshipit-source-id: d847117cbfe0a191dc1882898711693c6fda68cd
Summary:
This diff changes the type of the SwipeRefreshLayoutManager.size prop from Int to String in Fabric.
The current implementation of this prop allows JS developers to use "int" type when fabric is enables and "int or string" types when using Fabric is disabled.
Since long term we want to only support "string" type for this prop, I'm changing the type of the prop to be String.
After my diff Fabric will start supporting only "string" types, non fabric screens will keep supporting "int or string" values.
**Will this break production?**
No, because there are no usages of RefreshControl.Size prop in fbsource
**What about if someone start using this prop next week?**
IMO It's very unlikely because of the nature of this prop, I will be monitoring next week and if there's an usage it will be detected by flow when trying to land D25933457.
Changelog: [Android][Changed] - RefreshControl.size prop changed its type to string, the valid values are: 'default' and 'large'
Reviewed By: JoshuaGross
Differential Revision: D25933458
fbshipit-source-id: 55067d7405b063f1e8d9bb7a5fd7731f5f168960
Summary:
Changelog:
[Internal][Fixed] - Add a default value for the cache breaker value
Reviewed By: fkgozali
Differential Revision: D25907137
fbshipit-source-id: 243346cbc67d1a85519bb469f4d68d61676ba547
Summary:
Restore the `android_hyphenationFrequency` attribute in the view config for `Text`. This was accidentally dropped by D23708205 (06ce643565) (06ce643565).
Changelog:
[Android][Fixed] - Restore `android_hyphenationFrequency` on `Text`.
Reviewed By: mdvacca
Differential Revision: D25889971
fbshipit-source-id: 622eef618370efdd9a8b060ccd3272e25de218fa
Summary:
Changelog: [internal]
Revert a change introduced in https://github.com/facebook/react-native/pull/30333 where rickhanlonii asked it to be reverted as well.
The change breaks sticky header in Fabric.
Reviewed By: rubennorte
Differential Revision: D25883861
fbshipit-source-id: b01305c6def390d0664c7be939ab3fc72186a07a
Summary:
allow-large-files
Changelog: [iOS] Remove iOS10/tvOS10 suppport
Similar to D19265731 (674b591809) for iOS9.
I just ran this command:
`find . -type f -exec sed -i '' 's/{ :ios => "10.0" }/{ :ios => "11.0" }/' {} +`
and then updated pods
Reviewed By: fkgozali
Differential Revision: D25693227
fbshipit-source-id: 0073d57ecbb268c52d21962cef202316857bcbd2
Rick Hanlon
Xuan Huang
Jesse Katsumata
Altaibayar Tseveenbayar
Evan Yeung
Jason Safaiyeh
Mark Bridges
Nick Gerleman
Joshua Wiegmann
Kudo Chien
Adrián Cuesta
Tim Yung
Joshua Wiegmann
Anas Khurshid
Kacie Bawiec
Justin Huntington
Nishan Bende
Ruslan Serebriakov
Joshua Gross
Peter Argany
Luna Wei
David Vacca
Ramanpreet Nara
Arthur Lee
Martin Sherburn
Daniel Sainati
Samuel Susla
Birkir Gudjonsson
Andrei Shikov
Kermit
Shuhao Zhang
Rubén Norte
Håkon Knutzen
Janic Duplessis
Paige Sun
Dennis Urtubia
Evgen Filatov
Andrew Coates
Sladyn Nunes
Erich Graham
Connor Tumbleson
Subramanya Chakravarthy
Tien Pham
Adrien HARNAY
Neal Poole
Scott Kyle
Adam Cmiel
Nadiia D
Lulu Wu
Andy Chou
Carlos Cuesta
Héctor Ramos
Jorge Rossi
Brian Vaughn
Madhav Gharmalkar
Kevin Gozali
grgr-dkrk
Jimmy Zhang
Kazuki Yamashiro
Huzaifa
Bruno Castro
Lucas Santos
simek
Quentin Valmori
Shelly Willard
Huzaifa Khan
David Biedenbach
Yan Zhang
Hans Halverson
Sam Goldman
Pieter De Baets
Micha Reiser
Valentin Shergin
Brandon Baumgarten
sirpy
Vladislav Shabanov
Moti Zilberman
Igor Klemenski
