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:
As suggested by motiz88 on D28421692 (https://github.com/facebook/react-native/commit/883e0d5752b952c829c8d45504d3532f52bb272f), make sure to still report fatal "warnings".
Changelog:
[General][Fixed] Report fatal errors even if its `type` is "warn".
Reviewed By: motiz88
Differential Revision: D28815228
fbshipit-source-id: 8d3b77958ef687a4ce64bdfccbf6ce2dc5557eaf
Summary:
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:
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
