Summary: Replaced each view manager access with a getViewManager() function call. This will later be used to lazily load view manager classes by allowing java to avoid sending the entire list of view managers to JS.
Reviewed By: QueryConnectionException
Differential Revision: D9695788
fbshipit-source-id: 949858aa2f0b0b00b68e260461ba8f1d085cf07f
Summary: D10013265 introduces flow types for `PanResponder`. This diff fixes the facebook-internal flow errors that surface as a result.
Reviewed By: TheSavior
Differential Revision: D10035046
fbshipit-source-id: fbba3d61e68851dda2da4f8e98238e0fdb35a27e
Summary:
There were approximately 350 unused suppressions in xplat/js when checking with .flowconfig.android
The flow team is partially responsible for this, since our release process hasn't changed since we added the flowconfig. In the diff beneath this one, I added the functionality necessary for us to not add any more unused suppressions. To test it, I made this diff. The steps were:
1. Start iOS server
2. Start android server
3. remove unused ios suppressions
4. remove unused android suppressions
5. add ios suppressions with site=react_native_ios_fb
6. add android suppressions with site=react_native_android_fb
7. remove unused ios suppressions. The ones that are unused are ones where an android comment was inserted as well, since the ios comment no longer is next to the error
8. add suppressions using ios flowconfig with site=react_native_fb
9. remove unused android suppressions. The unused ones are ones that were moved up when the cross-platform suppressions were inserted.
I'm going to make this into a script to make sure we don't contribute anymore unused suppressions from our side.
The controller you requested could not be found. nolint
Reviewed By: TheSavior
Differential Revision: D10053893
fbshipit-source-id: 7bee212062f8b2153c6ba906a30cf40df2224019
Summary:
related #21342
The `render` function, I was not able to specifically type since the props passed to it may vary. At the moment only `renderRow` function from ListView component is using StaticRenderer, and the type of the renderRow function is `Function`.
Let me know what your thoughts are on this. Thank you
Pull Request resolved: https://github.com/facebook/react-native/pull/21348
Differential Revision: D10084990
Pulled By: TheSavior
fbshipit-source-id: a87a8d4976c6ffaf83dc0fddc758869dbc2e2803
Summary:
This PR splits EdgeInsetsPropTypes into EdgeInsetsPropTypes with only flow types and DeprecatedEdgeInsetsPropTypes inside DeprecatedProptypes with only PropTypes.
Related to #21342
Pull Request resolved: https://github.com/facebook/react-native/pull/21351
Reviewed By: RSNara
Differential Revision: D10081512
Pulled By: TheSavior
fbshipit-source-id: 267a6fbb455e02dd7f2b0f3b59790e96387eaa09
Summary:
related #21342
This is a first PR for this repo.
So, if there are any problem, please tell me 🙇
TODO
* delete props types
* apply read only interface
CheckList
- [x] `yarn prettier`
- [x] `yarn flow-check-ios`
Pull Request resolved: https://github.com/facebook/react-native/pull/21346
Differential Revision: D10081962
Pulled By: TheSavior
fbshipit-source-id: 32387c58f180b9aa5f854e323a4bb29aa73f04c8
Summary:
This PR moves `DeprecatedViewPropTypes` to a new `DeprecatedViewProps` folder, and copies all documentation comments to the relevant Flow types file.
Pull Request resolved: https://github.com/facebook/react-native/pull/21349
Differential Revision: D10080802
Pulled By: TheSavior
fbshipit-source-id: af4881f3b12e8a1e675b849e0fcf0cc57a68e57f
Summary:
This PR is the result of running `yarn prettify` on the codebase - which caught a few files that were not prettified. This will make instructing people to run prettify a bit less complicated, since unrelated files will not show up in diffs.
Pull Request resolved: https://github.com/facebook/react-native/pull/21327
Differential Revision: D10046057
Pulled By: TheSavior
fbshipit-source-id: 2c771a3c758c72816c707e32ee2f4587e466f277
Summary:
This flow type is wrong, probably just a copy paste mistake.
Pull Request resolved: https://github.com/facebook/react-native/pull/21271
Differential Revision: D10006741
Pulled By: TheSavior
fbshipit-source-id: eba0116ec39ba00f000d9bf789ae9214990355a1
Summary:
This PR exposes the `onScrollToTop` event on iOS using the same event-forwarding infrastructure as other ScrollView events. (As such, its `nativeEvent` object reflects the same fields as other ScrollView events.)
Motivation:
----------
If your app is only interested in knowing the position of a ScrollView after a scroll has completed, it can use `onScrollEndDrag` and `onMomentumScrollEnd` to inspect the `contentOffset` after a drag-initiated scroll has finished. (This is much less expensive than observing the `onScroll` event if you only want to know the end position.) However, neither of these `End` events fire if the ScrollView is scrolled to the top by tapping the status bar.
By exposing `onScrollToTop`, it is now possible for an app to cheaply know when such a scroll has completed.
Pull Request resolved: https://github.com/facebook/react-native/pull/21204
Differential Revision: D9943618
Pulled By: hramos
fbshipit-source-id: ac5ee42b7f12d94655ffda617f8f811138da7f6f
Summary:
This file was created recently but is not used as the WKWebview was integrated directly into the Webview.ios.js
Removing this file to clarify the situation
Pull Request resolved: https://github.com/facebook/react-native/pull/21182
Differential Revision: D9942905
Pulled By: hramos
fbshipit-source-id: 19e9fba94280428edd1deab4a54f8c5dc42a6bfa
Summary:
Currently the warning is always triggered, even on iOS. This simply adds a platform check and tweak the message.
Pull Request resolved: https://github.com/facebook/react-native/pull/21174
Differential Revision: D9929679
Pulled By: hramos
fbshipit-source-id: 383f4a820cf5bf261dbfdcff3b950f9812a65e00
Summary:
Adding the new `textContentType` options from iOS 12. `newPassword` helps the OS know to put a password field into the keychain, and `oneTimeCode` hints that the field will take input from an SMS one time code.
Pull Request resolved: https://github.com/facebook/react-native/pull/21079
Differential Revision: D9813328
Pulled By: TheSavior
fbshipit-source-id: d2c04b41121b32f185af38ea4c642924e261a043
Summary: This diff adds a new property in ReactWebView to be able to configure allowFileAccess
Reviewed By: achen1
Differential Revision: D9789466
fbshipit-source-id: 39d042ac6ef69e44f006a4c4b0c2dd900f84dbc9
Summary: In some cases, the custom implementation of this prop is undesirable, so this allows to turn it off.
Reviewed By: yungsters
Differential Revision: D9759228
fbshipit-source-id: 4f61cd900c2da9046977c11a61606a4f5f961177
Summary: This change drops the year from the copyright headers and the LICENSE file.
Reviewed By: yungsters
Differential Revision: D9727774
fbshipit-source-id: df4fc1e4390733fe774b1a160dd41b4a3d83302a
Summary:
Switches to the `nullthrows` package instead of using `fbjs/lib/nullthrows`.
The version of `nullthrows` in `fbjs` is outdated and already missing features that exist in the standalone `nullthrows` package.
Also, this mitigates the inevitable collision between `nullthrows` (as a Haste module) and `nullthrows` (as a `node_modules` dependency).
Reviewed By: zertosh
Differential Revision: D9733178
fbshipit-source-id: 1b589d48c1ed57cebf2088b796ad72e212534c0a
Summary:
Legacy navigator impl. There are other alternatives that should be used instead.
Part of the slimmening effort as described here: https://github.com/react-native-community/discussions-and-proposals/issues/6
Reviewed By: TheSavior
Differential Revision: D9677824
fbshipit-source-id: 24ae500751d2a8c398f246d36604a58f0b3c113b
Summary:
D8842691 split AccessibilityTraits into multiple RN properties. However, the accessor code did not support REMOVING traits.
This results in buttons that were disabled (AccessibilityTraits & NotEnabled === true) never being enabled.
Fix the issue by making the split accessors properly mask in the bits, allowing you unset them without disturbing bits managed by the other accessor.
NOTE: setting AccessibilityTraits and AccessibilityRole or AccessibilityStates will still result in bugs.
Reviewed By: shergin
Differential Revision: D9661970
fbshipit-source-id: 77d70dd0754f2eaf8cbf895bfc13757c697a76d8
Summary:
**Motivation**
Whenever a user changes the system font size to its maximum allowable setting, React Native apps that allow font scaling can become unusable because the text gets too big. Experimenting with a native app like iMessage on iOS, the font size used for non-body text (e.g. header, navigational elements) is capped while the body text (e.g. text in the message bubbles) is allowed to grow.
This PR introduces a new prop on `<Text>` and `<TextInput>` called `maxFontSizeMultiplier`. This enables devs to set the maximum allowed text scale factor on a Text/TextInput. The default is 0 which means no limit.
Another PR will add this feature to Android.
**Test Plan**
I created a test app which utilizes all categories of values of `maxFontSizeMultiplier`:
- `undefined`: inherit from parent
- `0`: no limit
- `1`, `1.2`: fixed limits
I tried this with `Text`, `TextInput` with `value`, and `TextInput` with children. For `Text`, I also verified that nesting works properly (if a child `Text` doesn't specify `maxFontSizeMultiplier`, it inherits it from its parent).
Lastly, we've been using a version of this in Skype for several months.
**Release Notes**
[GENERAL] [ENHANCEMENT] [Text/TextInput] - Added maxFontSizeMultiplier prop to prevent some text from getting unusably large as user increases OS's font scale setting (iOS)
Adam Comella
Microsoft Corp.
Pull Request resolved: https://github.com/facebook/react-native/pull/20915
Differential Revision: D9646739
Pulled By: shergin
fbshipit-source-id: c823f59c1e342c22d6297b88b2cb11c5a1f10310
Summary: Added `snapToStart` and `snapToEnd` props to ScrollView which work together with `snapToOffsets` and determine whether the beginning and end of the list automatically count as snap offsets or not. If not, the list is allowed to free-scroll between its start/end and the first/last snap offset.
Reviewed By: sahrens
Differential Revision: D9442386
fbshipit-source-id: 47a5fdb20f884542434b01b1f0a486ed2b478c6e
Summary:
* Added snapToOffsets prop to ScrollView. Allows snapping at arbitrary points.
* Fixed pagingEnabled not being overridden by snapToInterval on iOS.
* Fixed Android *requiring* pagingEnabled to be defined alongside snapToInterval.
* Added support for decelerationRate on Android.
* Fixed snapping implementation. It was not calculating end position correctly at all (velocity is not a linear offset).
* Resolves https://github.com/facebook/react-native/issues/20155
* Added support for new content being added during scroll (mirrors existing functionality in vertical ScrollView).
* Added support for snapToInterval.
* Resolves https://github.com/facebook/react-native/issues/19552
Reviewed By: yungsters
Differential Revision: D9405703
fbshipit-source-id: b3c367b8079e6810794b0165dfdbcff4abff2eda
Summary:
Makes a couple improvements to `ViewPropTypes`.
- Remove deprecated transform props. We are now using exact object types, so they are already disallowed.
- Remove garbage types for `accessibilityLabel`.
Reviewed By: TheSavior
Differential Revision: D9542088
fbshipit-source-id: f9128353e19cff22caf52c896c9c137f01aea276
Summary: This diff reverts the changes in the name for AndroidHorizontalScrollView and AndroidHorizontalScrollContentView that caused a redbox for continuous OTA users
Reviewed By: fkgozali
Differential Revision: D9561972
fbshipit-source-id: 3d8e9ee8bb6081107bc8d315af16885bb003148e
Summary: This diff implements the HorizontalScrollView component for Android Fabric C++, as part of this diff I also re-named the components AndroidHorizontalScrollContentView for RCTAndroidHorizontalScrollContentView and AndroidHorizontalScrollView for RCTAndroidHorizontalScrollView. This might sound against our plan of removing the RCT preffix, but it is to make it simpler to map components between current implementation of RN and Fabric (otherwise we don't know when to add the RCT preffix in Android side to find the right View Manager), later we can just remove the preffix from C++, Android, iOS and JS.
Reviewed By: shergin, achen1
Differential Revision: D9122729
fbshipit-source-id: e9299552857c6dd0c18abfa5fa49a3d50e221729
Summary: Apparently different apps have different implementations of view managers that support different props. This is a problem that we will need to address. Unfortunately, this means we can't have a static config defined in JS. We will need to find another approach to this problem.
Reviewed By: sahrens
Differential Revision: D9500178
fbshipit-source-id: b591559164fcf29f5fd43e13a0f2da15011491c6
Summary:
Changes the Flow prop types for `Image`, `Text`, and `View` to be nullable and optional.
This makes these components easier to compose.
Reviewed By: sahrens
Differential Revision: D9494285
fbshipit-source-id: c3f17147f063b31217b239a3abc085d1850f8df9
Summary: As we move these configs to JS from native, until we have codegen that ensures everything stays up to date, this adds a dev mode check to ensure they are consistent.
Reviewed By: yungsters
Differential Revision: D9475011
fbshipit-source-id: 9d6f7b6c649229cae569d840eda3d5f7b7aa7cb2
Summary: Reverting due to problems with prepack.
Reviewed By: gaearon
Differential Revision: D9482931
fbshipit-source-id: 0ec5d0fb80dab32a07521a465dd2a501e6bb4d30
Summary: This diff moves the prop-type definitions for View out into it's own file. We will be able to do this with a bunch of the prop-type definitions and then move them out into a deprecated npm package.
Reviewed By: yungsters
Differential Revision: D9444394
fbshipit-source-id: 4fd0a78533211b598ba2da4eb5015ffcc20bb675
Summary: When running a trace, reduce the noise from the `__DEV__`-only `ForwardRef(View)` elements.
Reviewed By: ejanzer
Differential Revision: D9445865
fbshipit-source-id: 7cfe87bab6dd62d3800d2ca239724b5063c55c89
Summary: This caught a few flow types that weren't defined for attributes that Android exposes. Ensuring that these stay in sync will be necessary for codegen in the future.
Reviewed By: sahrens
Differential Revision: D9444165
fbshipit-source-id: 8ee00af7b732c35d7f6befcdf79f77b73eac6a1b
Summary: Moving this config to native for android so we skip the native lookup for the config.
Reviewed By: yungsters
Differential Revision: D9415726
fbshipit-source-id: 84cac3f0dfa4f6ea8800de77676f1e2896ee463d
Summary:
Description:
------------
While creating a custom component I added a prop `style: ?ViewStyleProp`. When I tried to pass the following object
```
style={{
opacity: new Animated.Value(0),
}}
```
to this `style` prop I received a yellow box with the warning:
```
Warning: Failed prop type: Invalid prop `opacity` of type `object` supplied to `MyComponent`, expected `number`.
```
Then I browsed through the source code and found an inconsistency in types checks. Namely,
https://github.com/facebook/react-native/blob/master/Libraries/StyleSheet/StyleSheetTypes.js#L158 has the following declaration `opacity?: number | AnimatedNode`, whereas https://github.com/facebook/react-native/blob/master/Libraries/Components/View/ViewStylePropTypes.js#L50 is willing to accept **only** a `number`: `opacity: ReactPropTypes.number`.
Pull Request resolved: https://github.com/facebook/react-native/pull/20773
Differential Revision: D9464634
Pulled By: TheSavior
fbshipit-source-id: fa21f706cb890dbeec136f1c4fab468904cd284b
Summary:
@public
The `WKWebView` class doesn't expose a `scalesPageToFit` property, unlike `UIWebView`. Therefore, the `scalesPageToFit` RN prop is be a bit tricky to implement with `WKWebView`.
For the time being, this diff adds warnings to `<WebView/>` whenever `useWebKit={true}` and `scalesPageToFit` is set. I've also updated the documentation to reflect that we don't support `scalesPageToFit` prop with the new implementation of `<WebView/>`.
Reviewed By: shergin
Differential Revision: D6429271
fbshipit-source-id: adf858cb67ba221c70d6d6f1bd6cff505e90c365
Summary:
@public
This diff adds the `useWebKit` property to the `<WebView/>` React Native component. On iOS, when this property is true, we use `RCTWKWebView`. Otherwise, we use `RCTWebView`. On Android, this property does nothing.
Reviewed By: shergin
Differential Revision: D6423374
fbshipit-source-id: 006bfaaf12984fac0174c0b5bb897c009c026cd0
Summary:
When text is rendered in `WKWebView` WebKit component, the component itself can detect things like phone numbers, flight numbers, links, etc. and render them with additional functionality.
For example, when the text `apple.com` is detected, if the `link` data detector type is enabled, the web view will actually render a link that takes the user to the Apple home page.
In this diff, I implement the `dataDetectorTypes` prop. The data detector types supported are:
1. phoneNumber
1. link
1. address
1. calendarEvent
1. trackingNumber
1. flightNumber
1. lookupSuggestion
These enums are documented in the [[ https://developer.apple.com/documentation/webkit/wkdatadetectortypes | WKDataDetectorTypes docs ]].
Reviewed By: shergin
Differential Revision: D6392546
fbshipit-source-id: 4dd373f0ac52f898163cd959eeef6672e55b42a6
Summary:
HTML video elements can have the `autoplay` attribute, which forces them to play automatically whenever they load on the page.
In this diff, I introduce a new prop `mediaPlaybackRequiresUserAction`, which allows us to control whether video or audio element autoplays even when `autoplay` is set.
Reviewed By: shergin
Differential Revision: D6382256
fbshipit-source-id: 617508653910d600bc43f7f68c6dfd17ab1b6dd8
Summary:
For iPhones with small screen sizes (e.g: iPhone 5s), inside the `<WKWebView/>` component, videos will play in fullscreen mode. In this diff, I introduce a prop called `allowsInlineMediaPlayback` that when set to true, will allow videos to play inline.
**Note:** For videos to play inline, the HTML video element must also have a `playsinline` attribute on it.
Reviewed By: shergin
Differential Revision: D6379770
fbshipit-source-id: a0130720ffede6c24a90cad0c97a75b657d77017
Summary:
@public
`UIWebView` has been deprecated and replaced by `WKWebView`. This diff introduces a new component `WKWebView` that simply renders a `WKWebView` on iOS.
This is the first in the stack of many diffs that'll be required to fully replace `UIWebView` with `WKWebView` in the `<WebView/>` React Native component. Eventually, I hope to introduce a prop called `useWebKitImplementation`, which, when true, will force RN to use `WKWebView` instead of `UIWebView` for the `<WebView/>` component.
The only thing that's been implemented so far is the `source` property.
Reviewed By: mmmulani
Differential Revision: D6266100
fbshipit-source-id: 65862e34bd98db7fff0349cf26888afee43a56e4
Summary: Locking down view style so that invalid styles can't be passed into View.
Reviewed By: yungsters
Differential Revision: D9309097
fbshipit-source-id: 69e7e3c5626609cfd47c167027a55470c42228c8
Summary: Fixes the `Touchable` debug view. The `child.type` is no longer a subclass of `React.Component` and no longer has `displayName`. It should be fine to have a hard dependency on `Text` and `View`, because... what app does not use them?
Reviewed By: TheSavior
Differential Revision: D9232036
fbshipit-source-id: 06f4091bf8e21cada3af50def2fdd41a6ad84f79
