Summary:
Changelog: [Internal] - Update Animation examples to toggle useNativeDriver
There are issues when we toggle the native driver on and off. Where once off, the animations don't seem to update anymore, until we turn nativeDriver back on. See videos in testplan
Reviewed By: yungsters
Differential Revision: D29774939
fbshipit-source-id: cf6d70c1b574a87bb803510196dfb273b36de5e1
Summary:
I'm going to be flipping the default from autoglob on `fb_apple_library` to `True`. This prepares the target so that there are no behavior changes.
## Changelog: [Internal]
Reviewed By: natestedman
Differential Revision: D29769271
fbshipit-source-id: a20b4f99f00613c092461979b4afe61bdca9fe37
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: Changelog: [Internal] RNTester to only show the module description. Example descriptions to follow
Reviewed By: yungsters
Differential Revision: D29571326
fbshipit-source-id: 973e0031fedee805e75c010fbf59833205801640
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:
Fixes https://github.com/facebook/react-native/issues/31774.
This pull request resolves a problem related to accessing blobs greater than 64 KB on Android. When an object URL for such blob is passed as source of `<Image />` component, the image does not load.
This issue was related to the fact that pipe buffer has a limited capacity of 65536 bytes (https://man7.org/linux/man-pages/man7/pipe.7.html, section "Pipe capacity"). If there is more bytes to be written than free space in the buffer left, the write operation blocks and waits until the content is read from the pipe.
The current implementation of `BlobProvider.openFile` first creates a pipe, then writes the blob data to the pipe and finally returns the read side descriptor of the pipe. For blobs larger than 64 KB, the write operation will block forever, because there are no readers to empty the buffer.
https://github.com/facebook/react-native/blob/41ecccefcf16ac8bcf858dd955af709eb20f7e4a/ReactAndroid/src/main/java/com/facebook/react/modules/blob/BlobProvider.java#L86-L95
This pull request moves the write operation to a separate thread. The read side descriptor is returned immediately so that both writer and reader can work simultaneously. Reading from the pipe empties the buffer and allows the next chunks to be written.
## 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] [Fixed] - Fix support for blobs larger than 64 KB
Pull Request resolved: https://github.com/facebook/react-native/pull/31789
Test Plan:
A new example has been added to RN Tester app to verify if the new implementation properly loads the image of size 455 KB from a blob via object URL passed as image source.
<img src="https://user-images.githubusercontent.com/20516055/123859163-9eba6d80-d924-11eb-8a09-2b1f353bb968.png" alt="Screenshot_1624996413" width="300" />
Reviewed By: ShikaSD
Differential Revision: D29674273
Pulled By: yungsters
fbshipit-source-id: e0ac3ec0a23690b05ab843061803f95f7666c0db
Summary:
Refactors how `Typeface` style and weight are applied in React Native on Android.
- Unifies all style and weight normalization logic into a new `TypefaceStyle` class.
- Fixes font weight support for the Fabric renderer.
- De-duplicates code with `TextAttributeProps`.
- Simplified normalization logic.
- Fixes a rare crash due to `Typeface.sDefaultTypeface` (Android SDK) being `null`.
- Adds a new example to test font weights in `TextInput`.
- Adds missing `Nullsafe` and `Nullable` annotations.
- Clean up a bunch of obsolete inline comments.
Changelog:
[Android][Fixed] - Fixed a rare crash due to `Typeface.sDefaultTypeface` (Android SDK) being `null`.
[Android][Fixed] - Fixed font weight support for the Fabric renderer.
[Android][Added] - Added a new example to test font weights in `TextInput`.
Reviewed By: JoshuaGross
Differential Revision: D29631134
fbshipit-source-id: 3f227d84253104fa828a5561b77ba7a9cbc030c4
Summary:
Building from source in debug takes a very long time because native builds need to run for all supported architectures. It is possible to check which architecture the devices for which we are about to launch the app on are and build only for those. For most cases we can reduce the number of architectures we build for to 1 instead of 4, resulting in a large speedup of the build.
This is inspired by iOS which has a "Build for active architecture only" option. Since android doesn't really support this natively we can implement it here and also in react-native by reading the build properties that we pass and alter the abi we build for.
With fabric / codegen coming up I suspect that we might want to default to building c++ soon. This should ease the transition as builds won't be orders of magnitude slower.
See https://github.com/react-native-community/cli/pull/1388 for more context and how we use this new config to automatically detect running emulator architectures.
## Changelog
[Android] [Added] - Allow configuring ndk build architectures
Pull Request resolved: https://github.com/facebook/react-native/pull/31232
Test Plan:
Tested by setting reactNativeDebugArchitectures with different values in gradle.properties. Checked the build logs to see which architectures are being built. Also made sure release builds are not affected by this value.
Clean build
reactNativeDebugArchitectures not set
824.41s
reactNativeDebugArchitectures=x86
299.77s
Reviewed By: mdvacca
Differential Revision: D29613939
Pulled By: ShikaSD
fbshipit-source-id: d20a23d1d9bbf33f5afaaf3475f208a2e48c0e1a
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:
Latest Android Gradle plugin doesn't respond to ANDROID_NDK env variable, so I propagated it explicitly and included with recommended `ndkPath` clause.
Changelog: [Internal]
allow-large-files
Reviewed By: fkgozali
Differential Revision: D29593132
fbshipit-source-id: 0785fe92385037d2d4cf290c2462b299800b6928
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:
Changelog: [Internal] Fix things in RNTester
* Make SectionList-contentInset example iOS only and update styling
* Fix a typo in SectionList-onEndReached example
* Fix module example styling and pressed state styling for Android
Reviewed By: kacieb
Differential Revision: D29571327
fbshipit-source-id: 5cbb68781536e21ca73ca22b01343379306babd4
Summary: Changelog: [Internal] Update title when navigating to an example
Reviewed By: kacieb
Differential Revision: D29545092
fbshipit-source-id: 7ce2f7d978601a5e11e2d60a8fd17be0249ce122
Summary: Changelog: [Internal] - iOS title jumps currently due to SafeAreaView re-mounting because of the layout structure we use. Simplified the layout tree
Reviewed By: kacieb
Differential Revision: D29545113
fbshipit-source-id: 9ed764c1c9f3da7c58baf8028454859bd50ded60
Summary: Changelog: [Internal] - Move SectionList examples together. An interim state for next diff to add a 3rd level of navigation so each example is rendered in separate surface.
Reviewed By: kacieb
Differential Revision: D29480143
fbshipit-source-id: f7f10920bd4ab938665f17f0a80debaff55b9788
Summary:
Changelog:
[Internal] - Rename some types and components in RNTester to support work for tertiary levels of navigation.
module = component | api
moduleExample = an example of a certain feature a module
Reviewed By: kacieb
Differential Revision: D29381875
fbshipit-source-id: c348bcbb73aaf95e85928bb14080a097e685cc78
Summary:
Add a test case showing off a pressable sticky header to RNTester.
Note that this test case does not follow the styling of the other ScrollView Examples. I chose not to make it follow the styling because the existing examples need to be refactored later to not use custom buttons.
Changelog:
[General][Added] Add Pressable Sticky Header example to ScrollViewExamples in RNTester
Reviewed By: lunaleaps
Differential Revision: D29437827
fbshipit-source-id: 3ccee5df99bc6f00a04e1ecbd47fbe86b1eda4dc
Summary:
# See PR
https://github.com/facebook/react-native/pull/29728
# From PR Author
Using `PlatformColor` with border colors doesn't work currently when switching dark mode as the information is lost when converting to `CGColor`. This change keeps the border colors around as `UIColor` so switching to dark mode works.
```ts
<View
style={{
borderColor: DynamicColorIOS({ dark: "yellow", light: "red" }),
borderWidth: 1,
}}
>
...
</View>
```
This view will start with a red border (assuming light mode when started), but will not change to a yellow border when switching to dark mode. With this PR, the border color will be correctly set to yellow.
## Changelog
[iOS] [Fixed] - Allow PlatformColor to work with border colors
Pull Request resolved: https://github.com/facebook/react-native/pull/29728
Test Plan:
1. Assign a `PlatformColor` or `DynamicColorIOS` to a view border color.
2. Toggle between dark / light mode. See the colors change.
Reviewed By: lunaleaps
Differential Revision: D29268376
Pulled By: p-sun
fbshipit-source-id: 586545b05be0beb0e6e5ace6e3f74b304620ad94
Summary:
String type seems to be already supported by codegen, but it was not included in the list for command methods.
Changelog: [Internal]
Reviewed By: JoshuaGross
Differential Revision: D29306740
fbshipit-source-id: 44b267c09f471dc601759ed2f7211a9e0fc1bb90
Summary: Changelog: [Internal] - Update expectations on RNTester's Animated Moving Box example. We don't restore defaults for the animated value on unmount. Also adds a Reset option to the example.
Reviewed By: kacieb
Differential Revision: D29143505
fbshipit-source-id: abb1e87530313cfbfe9c4985e651667d28589a67
Summary:
Adding a minHeight property messed up some screenshot tests. T93437971
I'm honestly not sure why this happened since that ScrollView container has a fixed height set of 300, so it shouldn't have changed heights... It didn't change heights in RNTester.
We should probably take the full example (including title etc.) from RNTester for our E2E tests to avoid these types of weird layout breakages in the future.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D29201224
fbshipit-source-id: 30b98fa43d06eec1da345becc473690a3b075fb7
Summary:
Quick fix to fix a few test cases that had very small height buttons. (buttons became like this after flex: 1 was added to them in D29082450 (https://github.com/facebook/react-native/commit/f12f0e679dd6f1cdbd3c993d940a736ea1e952a3))
Added a minHeight to the buttons and added Views around groups of buttons.
Eventually we should update these examples to not use a custom button.
Changelog: [Internal]
Reviewed By: lunaleaps
Differential Revision: D29145288
fbshipit-source-id: 238c298a25b33da662b4897399f82ad0aa29b9cd
Summary:
I had an issue with the old version of the parser and upgrading it via `yarn resolve` solved it.
Pull Request resolved: https://github.com/facebook/react-native/pull/31490
Reviewed By: kacieb
Differential Revision: D29107863
Pulled By: PeteTheHeat
fbshipit-source-id: f8393dd52c10e6868e626cee75557b17b647bee8
Summary: Changelog: [Internal] - Update XHR upload example to new post test server. Created new toilet here: http://ptsv2.com/t/react-native and configured to return the link to the post data
Reviewed By: kacieb
Differential Revision: D29082824
fbshipit-source-id: 0cb502286addf1de3d5053f73173551ddd180a96
Summary: Changelog: [Internal] - Remove picker from Modal example in RNTester in prep for deprecating Picker from RN
Reviewed By: kacieb
Differential Revision: D29082452
fbshipit-source-id: 01ee5ae2d0978721f7229d824f23cfbccfaf2813
Summary: Changelog: [Internal] - Remove Picker from accessibility example as a first step to deprecate Picker from react-native
Reviewed By: kacieb
Differential Revision: D29082453
fbshipit-source-id: d1d6eb0514453126351b41c2ca5d72d2c81f5dc9
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:
Pull Request resolved: https://github.com/facebook/react-native/pull/31675
As requested in parent diff, moved the Android dep bumps into a separate diff.
## Changelog
[general][changed] - [Android] Update Flipper to 0.93.0
Reviewed By: mdvacca, ShikaSD
Differential Revision: D28688486
fbshipit-source-id: c3a8e0edeebdabd490b2885497e261f64bdab4bd
Summary:
Original PR: https://github.com/facebook/react-native/pull/31258
## Imported PR from Github:
This is a continuation of https://github.com/facebook/react-native/pull/29683. I've talked to danilobuerger who does not intend on continue work on it and is OK with me picking up where he left. This PR is identical besides adding a test case in the RN Tester app as requested in the original PR.
In summary it gives iOS feature parity with Android in the sense that one can use user-defined native colors, something even the docs claim is possible. It's useful as it enables accessibility features such as high contrast colors and makes implementing dark mode simple. For an example on how it can be used, see https://github.com/klarna-incubator/platform-colors
## Changelog
[iOS] [Added] - Allow PlatformColor to return user-defined named asset color
Pull Request resolved: https://github.com/facebook/react-native/pull/31258
Test Plan: Test case added to RN Tester.
Reviewed By: sammy-SC
Differential Revision: D28803206
Pulled By: p-sun
fbshipit-source-id: e0f0690274799bd2d09c9f9d1a6a95ac0f979498
