Summary:
part of #24875. iOS only it appears, but not really used by RN itself. Should be fine?
## Changelog
[General] [Added] - Add TM spec for KeyboardObserver
Pull Request resolved: https://github.com/facebook/react-native/pull/24881
Reviewed By: fkgozali
Differential Revision: D15391769
Pulled By: rickhanlonii
fbshipit-source-id: 557507f6063b40d1c68ec8739e23b33bc22ade39
Summary:
Set duration=0 for android keyboard events. Brings actual implementation closer to existing flowtypes, and duration is set to 0 to minimize impact on existing keyboard event consumers.
Follow up to #24947, upon cpojer's [input](https://github.com/facebook/react-native/pull/24947#issuecomment-494681618) :)
## Changelog
[Android] [Added] - Set duration=0 for android keyboard events
Pull Request resolved: https://github.com/facebook/react-native/pull/24994
Differential Revision: D15449394
Pulled By: cpojer
fbshipit-source-id: d43096238bd38d189fbec54fc2d93f17010d9ddb
Summary:
This pull request enhances the Keyboard API event emitter for Android upon `keyboardDidHide` by returning a `KeyboardEvent` with a meaningful `endCoordinates` property (instead of emitting a null as of current implementation). This change standardizes the `keyboardDidHide` keyboard event emission across both iOS and Android, which makes it easier for developers to use the API.
In particular, the semantics of `endCoordinates` emitted during the `keyboardDidHide` event on Android will match nicely with semantics of the same event emitted on iOS:
- `screenY` will be height of the screen, as that the keyboard has collapsed to the bottom of the screen
- `screenX` will be 0, as the keyboard will always be flush to the sides of the screen
- `height` will be 0, as the keyboard has fully collapsed
- `width` will be the width of the screen, as the keyboard will always extend to the width of the screen
Also, the flowtypes for `KeyboardEvent` have been further improved and are more explicit to better highlight the different object shapes (see `IOSKeyboardEvent` and `AndroidKeyboardEvent`) depending on the platform.
## Changelog
[Android] [Added] - Return endCoordinates for keyboardDidHide keyboard event
Pull Request resolved: https://github.com/facebook/react-native/pull/24947
Differential Revision: D15413441
Pulled By: cpojer
fbshipit-source-id: aa3998542b7068e9852467038f57310355018379
Summary: Allows iOS users to prefil from keyboard if they support safari autofill
Differential Revision: D15385599
fbshipit-source-id: 35d8a7a04c44d23d2aa27dffa02035b68818db7a
Summary:
`<VirtualizedList />` will throw an error if the `renderItem` Prop component uses hooks. Function components without hooks and class components work without issue.
Super contrived Example
```{js}
function FlatListItem({ item }) {
React.useEffect(() => console.log(item),[])
return (<Text>{item}</Text>);
}
<FlatList data={[1, 2, 3]} renderItem={FlatListItem} />
```
Example Error:
```
Invariant Violation: Hooks can only be called inside the body of a function component. (https://fb.me/react-invalid-hook-call)
This error is located at:
in CellRenderer (at VirtualizedList.js:688)
in RCTScrollContentView (at ScrollView.js:976)
in RCTScrollView (at ScrollView.js:1115)
in ScrollView (at VirtualizedList.js:1081)
in VirtualizedList (at FlatList.js:632)
in FlatList (at WithoutScrollbars.js:21)
...
```
## Changelog
[General] [Added] - VirtualizedList ListItemComponent. An alternative to renderItem that accepts function components with hooks.
[General][Added] - FlatList ListItemComponent. An alternative to renderItem that accepts function components with hooks.
[General][Added] - VirtualizedList and FlatList tests and updated RNTester example
Pull Request resolved: https://github.com/facebook/react-native/pull/24832
Reviewed By: sahrens
Differential Revision: D15334020
Pulled By: cpojer
fbshipit-source-id: 882db722fd6e22f07260b08091b3456d1c66c2c8
Summary:
This introduces a new library named "ReactPrivate" that defines an explicit interface between the React renderers generated by the React repo and the code within RN. Previously, the React renderers would reach into RN internals via Haste wormholes. With this commit, there is now an explicit module (`ReactNativePrivateInterface`) that the renderers use to access RN internals.
Motivation: The main goal is to move one step closer to turning off Haste for RN (https://github.com/facebook/react-native/issues/24316). Since the generated renderers currently use Haste, this commit sets the foundation for giving them a path-based interface to access RN internals.
Additionally, this approach inverts abstraction control since RN needs to intentionally export its internals via the private interface instead of React reaching in via Haste.
There will also need to be a corresponding commit to the React repo to make the renderers use this new interface. This RN commit needs to land before the React commit.
## Changelog
[General] [Changed] - Add a private interface (do not use) between the renderer and RN
Pull Request resolved: https://github.com/facebook/react-native/pull/24782
Differential Revision: D15413477
Pulled By: cpojer
fbshipit-source-id: 3766ad4cf129fad0c82f0ddc7a485a4ba313b2c4
Summary: Fixes a flow failure in the generated output and adds trailing commas to pass linting
Reviewed By: yungsters
Differential Revision: D15354725
fbshipit-source-id: 1eac27fa753af595a9a2787426b147e5f49a4e1d
Summary: This removes the NetInfo import from RN and moves it to FB internal. Follow-up diffs will move the Android and iOS files as well.
Reviewed By: rubennorte
Differential Revision: D15392486
fbshipit-source-id: b868b671b8d91661bc7634b4662074ae953835be
Summary:
The `Linking.openURL()` method is supposed to resolve to a `true` `Promise` when the URL was properly open. However, in iOS, the `Promise` was resolving to `nil`. So I fixed this issue by making it resolve to `YES` (`true`), just like on Android.
## Changelog
[iOS] [Fixed] - Fix return value of `Linking.openURL()`
Pull Request resolved: https://github.com/facebook/react-native/pull/24955
Differential Revision: D15411994
Pulled By: cpojer
fbshipit-source-id: 90bdd6cfae8d69d7a239a0b4c84d75859e293b32
Summary:
This is a reconstitution of #24190. It extends accessibility actions to include both a name and user facing label. These extensions support both standard and custom actions.
We've also added actions support on Android, and added examples to RNTester showing how both standard and custom accessibility actions are used.
## Changelog
[general] [changed] - Enhanced accessibility actions support
Pull Request resolved: https://github.com/facebook/react-native/pull/24695
Differential Revision: D15391408
Pulled By: cpojer
fbshipit-source-id: 5ed48004d46d9887da53baea7fdcd0e7e15c5739
Summary:
`scrollEventThrottle` is often a source of confusion, especially when using native animated since users expect that it doesn't affect `Animated.event` but it does. We added a default prop to Animated.ScrollView but not to `Animated.FlatList` and `Animated.SectionList` so this adds it for those.
## Changelog
[JavaScript] [Added] - Add default scrollEventThrottle to Animated{FlatList, SectionList}
Pull Request resolved: https://github.com/facebook/react-native/pull/24954
Differential Revision: D15411998
Pulled By: cpojer
fbshipit-source-id: 41589a96c0a8b75ae7cf3169ccef363ac5140ad3
Summary:
While working on https://github.com/facebook/react-native/pull/24893 I noticed the `WebSocket` module implementation on iOS was ignoring the code and reason arguments for the `close` method.
The Android implementation already handled those arguments properly.
So this PR brings iOS implementation on par with Android for the `WebSocket` module.
## Changelog
[iOS] [Fixed] - Fixed `code` and `reason` arguments ignored on iOS when calling `WebSocket.close`
Pull Request resolved: https://github.com/facebook/react-native/pull/24950
Differential Revision: D15411922
Pulled By: cpojer
fbshipit-source-id: f8a25598bd9c727313e24fea3801d5884d0723e4
Summary:
Straightforward.
Rick, I rename some stuff, I hope you are cool with that.
Reviewed By: mdvacca
Differential Revision: D15403306
fbshipit-source-id: 1dbd34060052a9bd39ed4211010f14b76fffcde6
Summary: Force `getConstants` in native modules to return an empty object when they're not defined in their native implementations.
Reviewed By: fkgozali
Differential Revision: D15393585
fbshipit-source-id: cdda9df0d0f0a98ba226340d3cee67fec63e106c
Summary:
1. Consistency with full stops (you can see screenshots in https://github.com/facebook/react-native/pull/24783 )
2. Improvements to the wording, describing what you're going to see
## Changelog
[Internal] [Fixed] - Improves the copy for the new app screen
Pull Request resolved: https://github.com/facebook/react-native/pull/24918
Differential Revision: D15391421
Pulled By: cpojer
fbshipit-source-id: 2ec6d2d5bd4845c5f4c699838ae865ab4217e49e
Summary:
In D15367312, I deprecate `$Enum<...>` in favour of `$Keys<...>` (the functionality is identical). Codemod existing usages in xplat and fbcode.
bypass-lint
Reviewed By: samwgoldman
Differential Revision: D15378084
fbshipit-source-id: 251c6b9ac07cb50139a8f03e3a45a5fac0d91812
Summary: This diff adds the android specific View view config props that I missed in an earlier diff in this stack
Reviewed By: cpojer
Differential Revision: D15336076
fbshipit-source-id: 6d20462b2682e3ea80b0ffc95ef35aa7618d4cf2
Summary:
## Overview
This diff switches the RCTSlider onSlidingComplete event on iOS from a bubbling event to a direct (non-bubbling) event to match the non-bubbling type on android.
Note that in this case these seems like a bug. I will still explain the motivation and reasoning as this will come up in future diffs.
## Changelog
[Slider][BREAKING] Switch Slider onSlidingComplete event to a non-bubbling event on iOS to match Android
## Motivation:
The motivation here is that when we codgen the view configs, we'll need to unify all of the events and props across platforms for components that have the same name on iOS and Android.
In this case, the view configs (below) conflict for onSlidingComplete. On iOS this is under bubblingEventTypes, on Android this is under directEventTypes. We have code [here](https://fburl.com/3s1dahm2) in the react native renderer which ensures an event is not listed as both.
```
// iOS
const SliderViewConfig = {
bubblingEventTypes: {
onSlidingComplete: {
phasedRegistrationNames: {
captured: 'onChangeCapture',
bubbled: 'onChange'
}
}
},
directEventTypes: {
// None
},
validAttributes: {
// ...
}
};
```
```
// Android
const SliderViewConfig = {
bubblingEventTypes: {
// None
},
directEventTypes: {
onSlidingComplete: {
registrationName: 'onEventDirect'
}
},
validAttributes: {
// ...
}
};
```
## Solutions
There are three solutions to this issue:
1. Don't generate view configs
2. Rename the component on one platform
3. Make a breaking change in the event behavior on one platform to make it consistent across both platforms
Here we've chosen option #3
Reviewed By: TheSavior
Differential Revision: D15322304
fbshipit-source-id: ff1ab86efe9e2bc50fd3f7619e6760ab5c1c5090
Summary: This diff adds a line to the codegen'd view configs which will check that all of the properties in the native view config are also in the JS view config we generate (note that the JS view config may have more properties than one native platform because it includes a union of both platforms)
Reviewed By: TheSavior
Differential Revision: D15278478
fbshipit-source-id: 0fef20c12265b952c69aca4e4c070a7d036db05a
Summary:
There has been push back to remove this module from React Native. Since it is contentious, let's revert the deprecation and table this conversation until later.
## Changelog
[General] [Changed] - Undeprecate StatusBar for now.
Pull Request resolved: https://github.com/facebook/react-native/pull/24860
Differential Revision: D15351835
Pulled By: cpojer
fbshipit-source-id: 2f40f3a8f17ab7631bf5441cd6528b04103e7821
Summary: This check isn't needed in prod as the bundle is served with the app. In dev mode it's possible to have native and JS out of sync.
Reviewed By: yungsters
Differential Revision: D15268485
fbshipit-source-id: 9aeeb6cf5ca91baa90b85e18c848c3b10d85b0f7
Summary: If some stack frames in a trace fail to symbolicate (or are genuinely unmapped), their `frame` field will be null, and `ExceptionsManager.js` will currently crash. This diff lets it recover gracefully and show whatever information is available.
Reviewed By: dcaspi
Differential Revision: D15296220
fbshipit-source-id: 2b1006b1354295171b25bfc6230c5b3e0c57f67f
Summary:
This PR is related to #24760 and adds the `openURLInBrowser` functionality introduced on react-native-community/cli#383.
[General] [Changed] - Open links from new app in computer's browser.
Pull Request resolved: https://github.com/facebook/react-native/pull/24843
Reviewed By: rickhanlonii
Differential Revision: D15334011
Pulled By: cpojer
fbshipit-source-id: 947ad1b113923989cf706e60851e02a87e1099e8
Summary:
first, I edited this post so that the comment below are NOT relevant any more
problem: `scrollToLocation` behavior in SectionList on master is inconsistent between platforms.
Recently, there have been two PRs changing this function: https://github.com/facebook/react-native/pull/21577 and https://github.com/facebook/react-native/pull/24034
let me just quote the [docs](https://facebook.github.io/react-native/docs/sectionlist#scrolltolocation) here
> Scrolls to the item at the specified sectionIndex and itemIndex (within the section)
originally, the code was `let index = params.itemIndex + 1;`
so if we call
```js
node.scrollToLocation({
animated: false,
itemIndex: 0,
sectionIndex: 0,
viewPosition: 0,
viewOffset: 0,
});
```
inside scrollToLocation, index is incremented and that results into the list scrolling to the first item (the first section heading is not visible - see the gif). If I specify `itemIndex = -1`, it will scroll all the way up. I was expecting `itemIndex = 0` to bring me all the way up, so that the first section heading is visible. Not sure which way this should work but at least this behavior is in line with the docs.
next, there was https://github.com/facebook/react-native/pull/21577 that changed it to
`let index = Platform.OS === 'ios' ? params.itemIndex: params.itemIndex - 1;`
so that https://github.com/facebook/react-native/issues/18098 is fixed. The PR had a bug and so next, there was https://github.com/facebook/react-native/pull/24034 that changed it to
`let index = Platform.OS === 'ios' ? params.itemIndex : params.itemIndex + 1;`
the reasoning was
> Note however, how the sign for non iOS changed from + to - causing a crash on Android when trying to scroll to index 0 as that will be evaluated to -1 instead of 1 and thus be out of bounds.
with this change, the list does not crash. However, the behavior is not consistent between platforms (see gifs):
So, this PR works under the assumption that
```js
node.scrollToLocation({
animated: false,
itemIndex: 0,
sectionIndex: 0,
viewPosition: 0,
viewOffset: 0,
});
```
should scroll all the way up, so that even the first section heading is visible. This should keep this bug https://github.com/facebook/react-native/issues/18098 fixed. However, this change means different behavior from how it used to be and from how it is documented, which should be pointed out in release notes and docs need to be updated.
Finally, if we agree this is the way to go, it'd be nice to have some automated tests.
cc melina7890 danilobuerger
[Android][Fixed] - fix scrollToLocation not consistent between platforms
Pull Request resolved: https://github.com/facebook/react-native/pull/24734
Differential Revision: D15334565
Pulled By: cpojer
fbshipit-source-id: f7122ef4a5c252fc3e0d2112861d1460742e9fa4
Summary:
This replaces the "new app screen" in the template with the new design from https://github.com/react-native-community/discussions-and-proposals/issues/122
This uses components that are shipped as part of the `react-native` module, but not necessarily as proper components exported by the main `react-native` module. To use these, we use absolute imports to those components.
Related to #24760
[General] [Changed] - Updated new app template design 💖
Pull Request resolved: https://github.com/facebook/react-native/pull/24805
Differential Revision: D15334459
Pulled By: cpojer
fbshipit-source-id: d0b67d08f936eeabd9e93d4e0ff78302b4d6429f
Summary:
We provided `ReactNetworkForceWifiOnly` in https://github.com/facebook/react-native/pull/24242, but it's a string type, actually the value only YES or NO, so let's change it to Boolean type, we can benefit from:
1. Users don't need to type string `YES`, just select bool YES or NO directly by click the button:
<img width="789" alt="image" src="https://user-images.githubusercontent.com/5061845/57634311-a8af7400-75d7-11e9-9f8a-ebf865d672e3.png">
2. Don't need to do string compare.
3. More looks what it should looks, Boolean is the Boolean. :)
cc. cpojer ericlewis .
[iOS] [Changed] - Change ReactNetworkForceWifiOnly from String to Boolean
Pull Request resolved: https://github.com/facebook/react-native/pull/24829
Differential Revision: D15323685
Pulled By: cpojer
fbshipit-source-id: c626d048d0cbea46d45f232906fd3ac32a412741
Summary:
Original commit changeset: f149721d6b4d (D15238379)
This commit was causing the following crash: Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'An instance 0x7fb3453eda00 of class RCTUITextField was deallocated while key value observers were still registered with it.
FB: See also P64445585 T44107377 T44169319
Reviewed By: mmmulani
Differential Revision: D15323255
fbshipit-source-id: 037c34ae387d912c5ea03eaa364b8c60367df357
Summary:
@public
RocksDB was originally available when RN open sourced but is no longer used, so removing it from AsyncStorage.js.
Changelog: [General] Removed RocksDB from AsyncStorage.js
Reviewed By: fkgozali
Differential Revision: D15218709
fbshipit-source-id: 82993f86bbb3f32e61d1e9895aafd67701351860
Summary:
Bugs like https://github.com/facebook/react-native/issues/24789, we don't apply tintColor to GIF. We fixes it by setting a poster image before add animation.
cc. cpojer .
[iOS] [Fixed] - Fixes renderingMode not applied to GIF images
Pull Request resolved: https://github.com/facebook/react-native/pull/24794
Differential Revision: D15316913
Pulled By: cpojer
fbshipit-source-id: 611a07ec17afc962d1eb6b8fc193f118fa623e73
Summary:
This adds in a link to the reactnative Twitter handle so our users can follow along with the latest and greatest of React Native!
Related to #24760
[General] [Added] - Added link to reactnative Twitter handle to Learn More section
Pull Request resolved: https://github.com/facebook/react-native/pull/24806
Differential Revision: D15316771
Pulled By: cpojer
fbshipit-source-id: cd45f005cfbcbd277fadb48be8943d60f4386767
Summary:
This is the next step in moving RN towards standard path-based requires. All the requires in `Libraries/vendor` have been rewritten to use relative requires. Talking to cpojer, the vendored code in RN can be modified directly.
This commit uses relative requires instead of `react-native/...` so that if Facebook were to stop syncing out certain folders and therefore remove code from the react-native package, internal code at Facebook would not need to change.
Closes#24769.
[General] [Changed] - Migrate vendored code from Haste to path-based imports
Pull Request resolved: https://github.com/facebook/react-native/pull/24807
Differential Revision: D15316831
Pulled By: cpojer
fbshipit-source-id: 19475823ce9f506600bd09b001156e306bff4db8
Summary:
On iOS in React Native, immediately after successfully connecting to a WiFi network, if 4G is also on, it is possible that network requests sent via fetch get sent over 4G instead of WiFi for several seconds (between 1 and 40+ seconds depending on the device and network in my experience). If the calls are meant to be communicating with a local Wireless Device (such as a wireless router, etc.), then API calls that get sent over 4G to the internet are lost. Note that Reachability/NetInfo are saying that we are connected to a WiFi network and are not sufficient to prevent this from happening. To prevent this, I would like to be able to set an instance property that iOS exposes for network requests allowsCellularAccess to NO to ensure a request is never sent over 4G.
This code needs to be able to accept a flag to allow the user to override the default value of YES, but only when they explicitly opt in to this decision. I am not sure the best place to set and pass in this value, so I created [this issue](https://github.com/react-native-community/discussions-and-proposals/issues/113), where it was recommended that I make a PR and discuss how best to do this here. Before this PR could be merged we would need to allow the NO to be configurable in some way.
Additional information about the [allowsCellularAccess](https://developer.apple.com/documentation/foundation/nsurlsessionconfiguration/1409406-allowscellularaccess?language=objc) property can be found in the [Apple documentation.](https://developer.apple.com/library/archive/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/Platform-SpecificNetworkingTechnologies/Platform-SpecificNetworkingTechnologies.html#//apple_ref/doc/uid/TP40010220-CH212-SW9)
[iOS] [Added] - Ability to force network requests to use WiFi using the allowsCellularAccess property. This can ensure that network requests are sent over WiFi if communicating with a local hardware device and is accomplished by setting a flag. Default behavior of allowing network connections over cellular networks when available is unchanged.
Pull Request resolved: https://github.com/facebook/react-native/pull/24242
Differential Revision: D15316760
Pulled By: cpojer
fbshipit-source-id: 96df43b4eff6b4301c853df6b2e5c6e1bb1abda0
