Summary:
Changelog: [internal]
collapsable was not passed to Fabric because view configs are built using Paper' ViewManagers.
Reviewed By: p-sun
Differential Revision: D27944688
fbshipit-source-id: 73a5646e25b3dd7a1a9dfc1079406047ab483d88
Summary:
In the full bridgeless, the following aren't allowed:
* using legacy view manager interop layer (won't support long term, but still needed today, so just warn)
* initializing any subclass of RCTViewManager (won't support long term, but still used by legacy interop layer)
* initializing RCTUIManager (fabric UIManager should be the only one used)
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D28111530
fbshipit-source-id: 4f5eab600c6c7896d51861545b7f878c25248e44
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: [iOS] Use visible prop to dismiss Modal on old renderer.
Visible prop is used on Fabric so that onDismiss can be passed with the the bridgeless per-component event emitter, rather than the bridge global event emitter. The old renderer still uses the global event emitter.
I needed to use the visible prop for Paper too because in diff 6/7, Modal.js [no longer uses visible prop to return null](dc80b2dcb5/Libraries/Modal/Modal.js (L221-L222)), and Modal.js can't distinguish on whether it's a Fabric or Paper component.
Reviewed By: JoshuaGross
Differential Revision: D28137929
fbshipit-source-id: f6ede0019fbe498a10b822ff09fc135a9fff8ec0
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:
Changelog: Fix possible sizing issue with DatePicker
Changing `preferredDatePickerStyle` changes size of the component without triggering re-layout of the react native screen. The fix is to make sure the size stays the same after changing the style.
Reviewed By: mdvacca
Differential Revision: D28035226
fbshipit-source-id: 2dcb50fd5ebaa0c0d01d3289c4ffa77a053cfc4a
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:
Problem: In paper, there is a handy API called `[uiManager viewForReactTag:]`. Fabric does not have this mapping. The Fabric interop layer still relies on this Paper mapping.
Solution: As a workaround, re-create this mapping in the Fabric interop layer. Therefore, whenever Fabric interop layer asks a paper view manager to create a view, store a weak reference to the view in a `NSMapTable`. NSMapTable allows us to customize the strong/weak relationship. I've added a comment explaining that `RCTWeakViewHolder` only needs to be used for this special circumstance.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27438899
fbshipit-source-id: 94663ef06479a8c863ce58b0f36d42109fa1c4f3
Summary:
Problem: In Paper rendering system, view managers are native modules that are created and retained by the bridge. Whenever rendering layer needs to create a view, it asks the bridge for the view manager. In bridgeless mode, these view managers are never created.
Solution: In bridgeless mode, let `RCTComponentData` create and retain a view manager. Having a 1:1 relationship of `RCTComponentData`:`ViewManager` is desirable, since their lifecycles should be similar. This implementation also maintains the lazy-instantiation behavior for bridgeless view managers.
Changelog: [Internal]
Reviewed By: RSNara
Differential Revision: D27375991
fbshipit-source-id: e76d966ba4b98972a49df1bc520b904fb2f4b3b5
Summary:
Picker was migrated to Fabric in stack ending in D23663596 (8f45db3b9e). Therefore, Picker's paper view manager is never used in Fabric through LegacyInteropLayer. This diff deletes a codepath that was created to accommodate this interop layer.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D27245596
fbshipit-source-id: e574e4aedcfef0ae639cb2aa446e27d6db5e9b94
Summary:
Changelog: [internal]
"onDismiss" event wasn't called in Fabric. This diff adds it.
Paper implementation of Modal uses `RCTEventEmitter` instead of callback to deliver the event. To align better with Paper, Fabric will follow this pattern.
Reviewed By: shergin
Differential Revision: D26911312
fbshipit-source-id: b0de619c5a02c3378d1f7ac3ce1b705bb5fb634d
Summary:
Since iOS 14 refresh control is sometimes visible when it shouldn't. It seems to happen when it is removed and added back to the window. This repros easily when using react-native-screens with react-navigation tabs. Inactive tabs are detached from the window to save resources.
Calling endRefreshing when refresh control is added to the window fixes the layout. It will also be called on first mount where it is not necessary, but should be a no-op and didn't cause any issues. I also decided to call it for all ios versions, although it is only needed on iOS 14+ to avoid forking behavior more.
## Changelog
[iOS] [Fixed] - Fix RefreshControl layout when removed from window
Pull Request resolved: https://github.com/facebook/react-native/pull/31024
Test Plan:
Before:
https://user-images.githubusercontent.com/2677334/108666197-93ea5a80-74a4-11eb-839b-8a4916967bf8.mov
After:
https://user-images.githubusercontent.com/2677334/108666223-9ea4ef80-74a4-11eb-8489-4e5d257299c8.mov
Reviewed By: shergin
Differential Revision: D26590759
Pulled By: PeteTheHeat
fbshipit-source-id: b8c06068a24446b261cbeb88ff166289724031f1
Summary:
This pull request is to fix https://github.com/facebook/react-native/issues/30258.
After an investigation, I found out the scroll offset of the list seems to be calculated incorrectly due to a workaround in the source code.
Instead of fixing the `calculateOffsetForContentSize`, I chose to remove it, the reason why I do so is because this workaround is for fixing the offset when `contentSize` is set manually, but according to the source code, there is no interface for a react-native user to set the `contentSize` of ScrollView, it is just set to `GCSizeZero` and will never be changed ([ref](https://github.com/facebook/react-native/pull/30647/files#diff-cf6f991f585ebf4cfdd555fe474e1f9ce40c2e4f823fc3f42b549414639c8c30L304)).
Also I changed the function name from `updateContentOffsetIfNeeded` to `updateContentSizeIfNeeded` according what the function is actually doing.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fixed] - Incorrect ScrollView offset on update
Pull Request resolved: https://github.com/facebook/react-native/pull/30647
Test Plan:
1. Create a fresh new project named `testapp` using npx create-react-native-app
2. Apply example code to `testapp` from https://snack.expo.io/lokomass/flatlist
3. Run `testapp` on iOS emulator and reproduce the bug
4. Make changes to files in `testapp/node_modules/react-native/`
5. Rebuild `testapp` and run on iOS emulator again, the bug is no more exist
6. Apply changes from step 4 to react-native, make a pull request.
#### Screenshots
Before: The scroll offset is incorrect after children of FlatList has changed
https://user-images.githubusercontent.com/48589760/103155130-b54a0580-47d7-11eb-97af-bdfd3e728714.mov
After: No more incorrect scroll offset if children of FlatList has changed
https://user-images.githubusercontent.com/48589760/103155091-6ef4a680-47d7-11eb-89fa-6f708bfef1c9.mov
Reviewed By: sammy-SC
Differential Revision: D25732958
Pulled By: shergin
fbshipit-source-id: dac6eff15ac3bbfec502452ac14b3d49fee76c29
Summary:
Fixes: https://github.com/facebook/react-native/issues/29455
Modal's onDismiss is not called on iOS.
This issue occurred the commit bd2b7d6c03 and was fixed the commit 27a3248a3b.
However, the master and stable-0.63 branches do not have this modified commit applied to them.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For an example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fixed] - Modal's onDismiss prop will now be called successfully.
Pull Request resolved: https://github.com/facebook/react-native/pull/29882
Test Plan:
Tested on iOS with this change:
1. Set function Modal's onDismiss prop.
1. Set Modal's visible props is true. (show Modal)
1. Set Modal's visible props is false. (close Modal)
1. The set function in onDismiss is called.
Reviewed By: shergin
Differential Revision: D24648412
Pulled By: hramos
fbshipit-source-id: acf28fef21420117c845d3aed97e47b5dd4e9390
Summary:
This diff ended up being a bit more complicated than I anticipated, since the source files in `ReactInternal` were depending on `RCTEventDispatcher`. I made the following changes:
1. Make `RCTEventDispatcher` a `protocol`, keep it in `ReactInternal`.
2. Rename the `RCTEventDispatcher` NativeModule to `RCTEventDispatcherModule`, make it conform to the `RCTEventEmitter` `protocol`, and move it to `CoreModules`.
3. Where necessary, replace categories of `RCTEventDispatcher` with functions.
Changelog:
[iOS][Added] - Make RCTEventDispatcher TurboModule-comaptible
Reviewed By: fkgozali
Differential Revision: D18439488
fbshipit-source-id: b3da15c29459fddf884519f33b0c3b8c036b5539
Summary:
Changelog: [internal]
This code was put in when we didn't have view commands implementation in Fabric. Now we do so let's get rid of it.
Reviewed By: JoshuaGross
Differential Revision: D24046269
fbshipit-source-id: d0f203bc09bf22f5307cb1844d14b295fe3550dd
Summary:
Refs: [0.62 release](https://reactnative.dev/blog/#moving-apple-tv-to-react-native-tvos), https://github.com/facebook/react-native/issues/28706, https://github.com/facebook/react-native/issues/28743, https://github.com/facebook/react-native/issues/29018
This PR removes most of the tvOS remnants in the code. Most of the changes are related to the tvOS platform removal from `.podspec` files, tvOS specific conditionals removal (Obj-C + JS) or tvOS CI/testing pipeline related code.
In addition to the changes listed above I have removed the deprecated `Platform.isTVOS` method. I'm not sure how `Platform.isTV` method is correlated with Android TV devices support which is technically not deprecated in the core so I left this method untouched for now.
## 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] [Removed]** - remove most of tvOS remnants from the code:
* `TVEventHandler`, `TVTouchable`, `RCTTVView`, `RCTTVRemoteHandler` and `RCTTVNavigationEventEmitter`
* **[Internal] [Removed]** - remove `TARGET_TV_OS` flag and all the usages
* **[iOS] [Removed]** - remove deprecated `Platform.isTVOS` method
* **[iOS] [Removed]** - remove deprecated and TV related props from View:
* `isTVSelectable`, `hasTVPreferredFocus` and `tvParallaxProperties`
* **[iOS] [Removed]** - remove `BackHandler` utility implementation
Pull Request resolved: https://github.com/facebook/react-native/pull/29407
Test Plan: Local tests (and iOS CI run) do not yield any errors, but I'm not sure how the CI pipeline would react to those changes. That is the reason why this PR is being posted as Draft. Some tweaks and code adjustment could be required.
Reviewed By: PeteTheHeat
Differential Revision: D22619441
Pulled By: shergin
fbshipit-source-id: 9aaf3840c5e8bd469c2cfcfa7c5b441ef71b30b6
Summary:
Wrap iOS 14 SDK code in a `#if/#endif` so that the Instagram app compiles again
Changelog: [Internal]
Reviewed By: PeteTheHeat
Differential Revision: D23948336
fbshipit-source-id: 67e6ee48d1951ae405c12b4ad39cf8c9817df627
Summary:
iOS14 has introduced new styles for date picker. The default new calendar style breaks the old spinner type style.
This is a workaround to keep the spinner style as a default, until the calendar style is properly supported. According to [this github comment](https://github.com/react-native-community/datetimepicker/issues/285) it works well.
This will fix DatePicker for both Fabric and Paper, since Fabric uses the interop layer to render it.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D23935328
fbshipit-source-id: 1a7fadba274e0537f0ac4ced60e23e7c809d57dc
Summary:
With the upgrade to React Native 0.63, we started running into nullability warnings that were breaking our build. This PR fixes those nullability warnings as well as a few other warnings in React-Core.
## Changelog
<!-- Help reviewers and the release process by writing your own changelog entry. For example, see:
https://github.com/facebook/react-native/wiki/Changelog
-->
[iOS] [Fixed] - Fix xcodebuild warnings in React-Core
Pull Request resolved: https://github.com/facebook/react-native/pull/29622
Test Plan:
- Nullability annotations should only affect compilation, but even though RNTester compiles, I'm not fully convinced that this won't break projects downstream. It would be good to get another opinion on this.
- The change in `RCTAllocateRootViewTag` is the only real logic change in this PR. We throw an exception if the root view tag is not in the correct format, so this change seems safe after some basic manual testing in RNTester.
Reviewed By: shergin
Differential Revision: D23386678
Pulled By: appden
fbshipit-source-id: a74875195a4614c3248e8f968aa98602e3ee2de0
Summary:
Fix a issue that RCTModalHostView can't be dismissed while being presented
Steps To Reproduce
A native modal presented view controller is being dismissed before the first screen shows.
A RCTModalHostView is presented when the first screen shows.
The RCTModalHostView will be dismissed after an asynchronous callback.
If the callback was called before the completion of the presenting animation, the RCTModalHostView will not be dismissed.
## Changelog
[iOS] [Fixed] - Fix that RCTModalHostView can't be dismissed while being presented
Pull Request resolved: https://github.com/facebook/react-native/pull/29745
Reviewed By: shergin
Differential Revision: D23566487
Pulled By: sammy-SC
fbshipit-source-id: bd95f200b79fa75e2387e402091d58c0f538759c
Summary:
Changelog: [Internal]
# Problem
In D22274782 (fb2b49d298) I removed integration between Paper and Fabric. However this integration was still used by `RCTLegacyViewManagerInteropComponentView` for view commands dispatch.
Fix is to use `[RCTUIManager viewForReactTag:viewTag]` instead of viewRegistry.
Reviewed By: shergin
Differential Revision: D23291567
fbshipit-source-id: 35c50716fd8b86ae25b1534e4d8aa688c8e6e129
Summary:
This function is unused. (Followup to D21941946)
Changelog: [iOS] Deprecate calculateChildFrames from RCTScrollView
Reviewed By: sammy-SC
Differential Revision: D22071415
fbshipit-source-id: 0c996ab02df1431ee9cfa082bc99681a2ec7118c
Summary:
Fixes some comment typos, moves hit testing and accessibility code so it's beside each other.
No functionality changes.
Changelog:[Internal]
Reviewed By: RSNara
Differential Revision: D22003047
fbshipit-source-id: 0e785364d7e1a080034d24c9676a56acb45686bb
Summary:
Changelog:
[iOS][Removed] - Removed DEPRECATED_sendUpdatedChildFrames prop to ScrollView component because there are no callsites of it anymore
Reviewed By: shergin
Differential Revision: D21941946
fbshipit-source-id: 0b7d6d0986ddff4b250e70e0450a6f7e166b41f4
Summary:
See discussion on c68195929b (commitcomment-38965326)
This PR fixes skewX/skewY/perspective/matrix on iOS as seen on this video: https://youtu.be/LK9iOKk62nw?t=115
## Changelog
[iOS] [Fixed] Bug with skewX/skewY/perspective/matrix transforms.
Pull Request resolved: https://github.com/facebook/react-native/pull/28863
Test Plan:
Try that the following transform as been fixed on iOS
```tsx
<View
style={{ transform: [{ rotateZ: Math.PI / 2}, { skewX: Math.PI/6 }] }}
/>
```
Differential Revision: D21493022
Pulled By: shergin
fbshipit-source-id: 4bf3550941e8acd8fdb87fe1143b21639c95b059
Summary:
This adds a `minimumSize` property to RCTRootView, and forwards any changes to it's shadow view. This **does not** change any default behaviour, as the default minimum size is `CGSizeZero` before & after this diff.
Changelog: [iOS][Internal] Add minimumSize to RCTRootView & RCTRootShadowView
Reviewed By: RSNara
Differential Revision: D20905456
fbshipit-source-id: a03f880e782891f60ef86b9c898965e05a5e796e
Summary:
This Pull Request implements the PlatformColor proposal discussed at https://github.com/react-native-community/discussions-and-proposals/issues/126. The changes include implementations for iOS and Android as well as a PlatformColorExample page in RNTester.
Every native platform has the concept of system defined colors. Instead of specifying a concrete color value the app developer can choose a system color that varies in appearance depending on a system theme settings such Light or Dark mode, accessibility settings such as a High Contrast mode, and even its context within the app such as the traits of a containing view or window.
The proposal is to add true platform color support to react-native by extending the Flow type `ColorValue` with platform specific color type information for each platform and to provide a convenience function, `PlatformColor()`, for instantiating platform specific ColorValue objects.
`PlatformColor(name [, name ...])` where `name` is a system color name on a given platform. If `name` does not resolve to a color for any reason, the next `name` in the argument list will be resolved and so on. If none of the names resolve, a RedBox error occurs. This allows a latest platform color to be used, but if running on an older platform it will fallback to a previous version.
The function returns a `ColorValue`.
On iOS the values of `name` is one of the iOS [UI Element](https://developer.apple.com/documentation/uikit/uicolor/ui_element_colors) or [Standard Color](https://developer.apple.com/documentation/uikit/uicolor/standard_colors) names such as `labelColor` or `systemFillColor`.
On Android the `name` values are the same [app resource](https://developer.android.com/guide/topics/resources/providing-resources) path strings that can be expressed in XML:
XML Resource:
`@ [<package_name>:]<resource_type>/<resource_name>`
Style reference from current theme:
`?[<package_name>:][<resource_type>/]<resource_name>`
For example:
- `?android:colorError`
- `?android:attr/colorError`
- `?attr/colorPrimary`
- `?colorPrimaryDark`
- `android:color/holo_purple`
- `color/catalyst_redbox_background`
On iOS another type of system dynamic color can be created using the `IOSDynamicColor({dark: <color>, light:<color>})` method. The arguments are a tuple containing custom colors for light and dark themes. Such dynamic colors are useful for branding colors or other app specific colors that still respond automatically to system setting changes.
Example: `<View style={{ backgroundColor: IOSDynamicColor({light: 'black', dark: 'white'}) }}/>`
Other platforms could create platform specific functions similar to `IOSDynamicColor` per the needs of those platforms. For example, macOS has a similar dynamic color type that could be implemented via a `MacDynamicColor`. On Windows custom brushes that tint or otherwise modify a system brush could be created using a platform specific method.
## Changelog
[General] [Added] - Added PlatformColor implementations for iOS and Android
Pull Request resolved: https://github.com/facebook/react-native/pull/27908
Test Plan:
The changes have been tested using the RNTester test app for iOS and Android. On iOS a set of XCTestCase's were added to the Unit Tests.
<img width="924" alt="PlatformColor-ios-android" src="https://user-images.githubusercontent.com/30053638/73472497-ff183a80-433f-11ea-90d8-2b04338bbe79.png">
In addition `PlatformColor` support has been added to other out-of-tree platforms such as macOS and Windows has been implemented using these changes:
react-native for macOS branch: https://github.com/microsoft/react-native/compare/master...tom-un:tomun/platformcolors
react-native for Windows branch: https://github.com/microsoft/react-native-windows/compare/master...tom-un:tomun/platformcolors
iOS
|Light|Dark|
|{F229354502}|{F229354515}|
Android
|Light|Dark|
|{F230114392}|{F230114490}|
{F230122700}
Reviewed By: hramos
Differential Revision: D19837753
Pulled By: TheSavior
fbshipit-source-id: 82ca70d40802f3b24591bfd4b94b61f3c38ba829
Summary:
`nativeId` type is `NSString`, not `NSNumber`. The `.h` file already has the proper type but `.mm` had a wrong one.
Changelog: [Internal]
Reviewed By: sammy-SC
Differential Revision: D20135465
fbshipit-source-id: e5f9fbf4940d3883334c910f96f0aa850a069d8c
Summary:
The accessibility roles and states description strings are not able to be localized on iOS platform. Those strings are exposed to the end users so it should be localized. This PR is to add localized strings as a resource bundle to the React Core Pod so that any React Native app integrating the React Native dependencies using CocoaPods can get the localized accessibility roles and states description.
## Changelog
[iOS] [Added] - Add localized accessibility strings to React Core pod
Pull Request resolved: https://github.com/facebook/react-native/pull/27995
Test Plan: Verified with RNTester app.
Differential Revision: D19975587
Pulled By: PeteTheHeat
fbshipit-source-id: f8eb4e25194f0cd603c98a6221ec87503a2826ed
Summary:
Starting on iOS 13, a View Controller presented modally will have a "bottom sheet" style unless it's explicitly presented full screen.
Before this, modals on iOS were only being dismissed programatically by setting `visible={false}`. However, now that the dismissal can happen on the OS side, we need a callback to be able to update the state.
This PR reuses the `onRequestClose` prop already available for tvOS and Android, and makes it work on iOS for this use case.
Should fix https://github.com/facebook/react-native/issues/26892
## Changelog
[iOS] [Added] - Add support for onRequestClose prop to Modal on iOS 13+
Pull Request resolved: https://github.com/facebook/react-native/pull/27618
Test Plan:
I tested this using the RNTester app with the Modal example:
1. Select any presentation style other than the full screen ones
2. Tap Present and the modal is presented
3. Swipe down on the presented modal until dismissed
4. Tap Present again and a second modal should be presented
![Screen Recording 2019-12-26 at 14 05 33](https://user-images.githubusercontent.com/8739/71477208-0ac88c80-27e9-11ea-9342-8631426a9b80.gif)
Differential Revision: D19235758
Pulled By: shergin
fbshipit-source-id: c0f1d946c77ce8d1baab209eaef7eb64697851df