Summary: `Viewable` is a weird name - I think `ViewToken` is more clear? Also easier to grep for.
Reviewed By: yungsters, bvaughn
Differential Revision: D4600762
fbshipit-source-id: dbfa5eec1b91166c4889dcb6b87d7832090be9e9
Summary:
It's pretty common to want to wait until the user scrolls a view to consider any items
viewable, so `waitForScroll` enables that behavior.
It's also pretty common to want to ignore items that are quickly scrolled out of view, so we add
`minViewTime` to handle that case.
Reviewed By: bvaughn
Differential Revision: D4595659
fbshipit-source-id: 07bc8e89db63cb68d75bdd9bedde3183c38a3034
Summary:
[Xcode](https://developer.apple.com/xcode/) is spelled with a lowercase `c`. 😄
**Test plan (required)**
ctrl-f project for `XCode`, case sensitive, find-and-replace with `Xcode`.
Make sure tests pass on both Travis and Circle CI.
Closes https://github.com/facebook/react-native/pull/12572
Differential Revision: D4622075
Pulled By: hramos
fbshipit-source-id: d64f0b10254cd624a71844ebaefa6fc29bc1ea57
Summary:
Lists need to be separated by a blank line from the preceding paragraph in order to render properly.
Closes https://github.com/facebook/react-native/pull/12521
Differential Revision: D4619863
Pulled By: ericvicenti
fbshipit-source-id: 4d5019af5ad66d8f4360339f007cf7f39427a945
Summary:
This PR is based on files ericvicenti gave me. Specifically, he gave me:
- AccessibilityInfo.android.js
- AccessibilityInfo.ios.js
- AccessibilityInfoModule.java
Before this change, only a native iOS implementation of AccessibilityInfo existed. This change includes:
- A native Android implementation of AccessibilityInfo.
- JavaScript wrappers for the AccessibilityInfo module for both iOS and Android.
- UIExplorer changes to illustrate how to use AccessibilityInfo on iOS and Android.
- Documentation for the AccessibilityInfo APIs.
**Test plan (required)**
Tested the UIExplorer AccessibilityInfo example on iOS and Android with the screen reader both enabled and disabled.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/12273
Reviewed By: mkonicek
Differential Revision: D4527224
Pulled By: ericvicenti
fbshipit-source-id: d04638465ccbdbb35ecfc9504daaeb8e33aab57a
Summary:
* The dev support code moved into a `DevSupport` subspec, meaning that only if the subspec is specified in the user’s Podfile will the packager client, dev menu, etc be included. This is mainly done through checks for header availability.
It also improves the weird situation where you had to specify the `RCTWebSocket` subspec if you wanted to be able to use the packager client during development.
* I removed hardcoding the release version in the podspec on release, because the podspec still relies on `package.json` when evaluating, so there’s no real point in not also getting the version number from there. This should remove any requirement to perform maintenance of the OSS release script regarding the podspec.
Closes https://github.com/facebook/react-native/pull/12602
Differential Revision: D4621021
Pulled By: ericvicenti
fbshipit-source-id: 6c208371fc40ea607809a6ab05dd3714ed9980cf
Summary:
it gives the wrong impression that a ListView has the restriction to only align the items vertically
The problem the PR addresses is that the documentation currently gives the initial impression that a ListView can only stack the items vertically.
Closes https://github.com/facebook/react-native/pull/12564
Differential Revision: D4622096
Pulled By: hramos
fbshipit-source-id: ce634087d143a28904d998a4c7301ca18392714e
Summary:
Similar to https://github.com/facebook/jest/pull/2877, this introduces an optional config `HasteImpl` of type `{getHasteName(filePath: string): (string|void)}` that returns the haste name for a module at filePath if it is a haste module or undefined otherwise.
This allows us to inject a custom implementation of haste's module id resolution rather than only relying on `providesModule` annotations
Reviewed By: davidaurelio
Differential Revision: D4589372
fbshipit-source-id: 4d1983dfbf09c9d67faf725e86ae86ab42433b7d
Summary:
Nothing actually changed except the deprecation.
Existed `intrinsicSize` was already implemented as `intrinsicContentSize` and this change only removes redundancy.
Moreover, we do not need `rootViewDidChangeIntrinsicSize` delegate method anymore; this is now mentioned in its description.
Depends on D4577890
Reviewed By: mmmulani
Differential Revision: D4589344
fbshipit-source-id: 16ed62cbf6bf72678bd7f7c11d4812c5aa36c743
Summary:
Now RCTRootView is much more reliable citizen of UIKit, it got:
* Implemented `sizeThatFits:`;
* Implemented `instrinsicContentSize`;
* Notifying superview via `setNeedsLayout` about changed size.
All it make possible painless integration of ReactNative-powered widgets inside existing native apps.
Reviewed By: javache
Differential Revision: D4577890
fbshipit-source-id: 9897cb002c9d658a97fd436240c2ac947ba2084b
Summary:
Moves stack trace symbolication to a worker process.
The worker process is spawned laziliy, and is treated as an exclusive resource (requests are queued).
This helps keeping the server process responsive when symbolicating.
Reviewed By: cpojer
Differential Revision: D4602722
fbshipit-source-id: 5da97e53afd9a1ab981c5ba4b02a7d1d869dee71
Summary:
This PR allows anyone to publish templates for React Native.
It's possible for people to publish modules for React Native, we should also support custom templates. A suggestion from a Cordova mantainer where they did the same thing suggests this is useful:
https://github.com/mkonicek/AppTemplateFeedback/issues/1
I published a sample template [react-native-template-demo](https://www.npmjs.com/package/react-native-template-demo).
(GitHub: https://github.com/mkonicek/react-native-template-demo)
With this PR anyone can then use that template:
`react-native init MyApp --template demo`
The convention is: if someone publishes an npm package called `react-native-template-foo`, people can use it by running `react-native init MyApp --template foo`.
Use a template called `react-native-template-demo` from npm:
`react-native init MyApp --template demo`
Use a local template:
`react-native init MyApp --template file:///path_to/react-native-template-dem
Closes https://github.com/facebook/react-native/pull/12548
Differential Revision: D4620567
Pulled By: mkonicek
fbshipit-source-id: bb40d457a7fec28edb577f08137e73241072de3a
Summary:
Android API 15 still have 1.5~2.0% distribution (refer: [Dashboard - Android Developer](https://developer.android.com/ndk/guides/standalone_toolchain.html#creating_the_toolchain)).
React Native is a good tec but many companies cannot endure loose their consumer. [Choreographer](https://developer.android.com/reference/android/view/Choreographer.html) triggered UI operation is the only reason that React Native Android sdk use minSdkVersion 16, so we can use a backward solution **only in API 15**: [Handler](https://developer.android.com/reference/android/os/Handler.html).
In this PR, the biggest change is :
- Make core operation of ReactChoreographer to an interface: ReactUIDriver;
- Impl ReactUIDriver by Handler => UIDriverHandlerImpl, refactor ReactChoreographer to UIDriverChoreographerImpl;
- Let UIDriverFactory to choose which one impl would be in use. (Only use handler in api 15).
Closes https://github.com/facebook/react-native/pull/12396
Reviewed By: AaaChiuuu
Differential Revision: D4588399
Pulled By: astreet
fbshipit-source-id: 76408e53664314dd926e6a553cde6bafbd37779e
Summary:
This PR fixes#6332
The issue is that Android Framework will return the same drawable instance for all requests if they request for the same resource. So the changes on the drawable instance will affect all users(`TextInput` in this case). The solution is very easy, call `mutate()` before change it will get a new drawable instance which make sure the change doesn't affect other users.
Closes https://github.com/facebook/react-native/pull/12493
Differential Revision: D4620034
Pulled By: astreet
fbshipit-source-id: a7b10fbc7447e01132b7ca0e1f78413796493e07
Summary:
**Motivation**
This PR fixes the flow type definition of StackFrame in parseErrorStack.js. The methodName was missing and the column could be `null`. We integrate with it in our codebase and we wanted to use `methodName`, but flow complained.
Refer to this file for possible values: [github.com/errwischt/stacktrace-parser/blob/master/lib/stacktrace-parser.js](https://github.com/errwischt/stacktrace-parser/blob/master/lib/stacktrace-parser.js)
This also allowed me to remove a flow error suppression.
**Test plan (required)**
I ran flow on the project, no errors
Closes https://github.com/facebook/react-native/pull/12499
Differential Revision: D4619885
Pulled By: ericvicenti
fbshipit-source-id: 0bf5a2304cb0dc9f2c6df026a5cee71c8a419c01
Summary:
On Android it's generally expected that alerts are dismissible by tapping outside the alert box. This is the default behavior for React Native, but until now there has been no means to listen for the dismiss event.
`Alert.alert` already takes an `options` object, so this pull request simply adds an additional option `onDismiss`, a callback function that will be called when an Alert is dismissed (rather than being closed as a result of a button press).
**Test plan**
Simply pass an `options` object to `Alert.alert` with the `onDismiss` property set to a function.
e.g. Run the following on Android, dismiss the alert by tapping outside the alert view, and monitor console output.
```
Alert.alert(
'Alert Title',
'My Alert Msg',
[
{text: 'Ask me later', onPress: () => console.log('Ask me later pressed')},
{text: 'Cancel', onPress: () => console.log('Cancel Pressed'), style: 'cancel'},
{text: 'OK', onPress: () => console.log('OK Pressed')},
],
{ onDismiss: () => console.
Closes https://github.com/facebook/react-native/pull/12594
Differential Revision: D4619862
Pulled By: ericvicenti
fbshipit-source-id: fdd351a7b8e673dab331f0e22dc5ea2e84f24375
Summary:
I ran into confusion (#12581) because the docs for TouchableOpacity stated that it doesn't change the view hierarchy, but in fact it does, and the docs are just out of date.
- [20 Feb 2015](efae175a8e/Libraries/Components/Touchable/TouchableOpacity.js (L21)) Docs correctly reflected that the component was cloned so didn't affect hierarchy
- [25 Jul 2015](725053acfe) Component was changed to being wrapped but docs weren't updated.
Went to correct this in the docs and noticed they were a bit inconsistent with each other, so have made them more unified. Each one now clearly warns about:
- If it adds a view to the hierarchy, which will affect layout.
- If it can only accept a single child.
Closes https://github.com/facebook/react-native/pull/12583
Differential Revision: D4619837
Pulled By: ericvicenti
fbshipit-source-id: 4d1becd9f290cefcb4548a5ea2878be2d2c315fa
Summary:
The new `ViewabilityConfig` API has a typo:
`itemVisiblePercentThreashold` should be `itemVisiblePercentThreshold`.
Thought it would be good to fix this before people start depending on a property containing a typo :-)
Updated tests to match.
Closes https://github.com/facebook/react-native/pull/12593
Differential Revision: D4619798
Pulled By: ericvicenti
fbshipit-source-id: 0aa8b6cf9ae7e5638607195759e4bd51140667fe
Summary: Renaming since a file with the same name as a package confuses packager
Reviewed By: cpojer
Differential Revision: D4613215
fbshipit-source-id: 5cfae71d0bb1eef2675689b37a9b42596d25678d
Summary: Adding providesModule annotations to files that don't have a `providesModule` annotation but are in directories that packager crawls.
Reviewed By: cpojer
Differential Revision: D4612455
fbshipit-source-id: b23f0d6bbe2d26f480e93b56b67c6c8b1075e9f7
Summary:
Nothing about the web prevents people from providing good visual feedback on touch events. I'm not trying to be a punk, just coming across this language (several times now) gives me weird feelings since I come from "the web".
Closes https://github.com/facebook/react-native/pull/12484
Differential Revision: D4608430
Pulled By: hramos
fbshipit-source-id: 9ab72bffb300aa7bd76b6e07470dfe9763e50556
Summary:
Created a containerized environment to run unit and integration tests for both javascript and android as well as a Jenkinsfile using the new 2.0 Pipeline syntax for integration into a Jenkins CI cluster.
Here is a quick summary of the changes:
* The android image is built from two separate dockerfiles. There is a base image that handles the heavy lifting of dependencies that are infrequently changed while the secondary image extends the base and allows for much quicker incremental builds on code updates.
* The javascript image is simple and is relatively quick to build, therefore there is no base image for any react specific javascript dependencies and it is all packaged in a single docker image.
* A new `scripts/docker` has been created including some javascript files and shell scripts to aid in the running of the tests
* The instrumentation test runner script can be passed various flags to control which tests run since the entire suite takes a significant amount of time to run synchronously
* Jen
Closes https://github.com/facebook/react-native/pull/11902
Differential Revision: D4609238
Pulled By: ericvicenti
fbshipit-source-id: a317f3ac3be898180b009254a9604ca7d579a8b9
Summary:
Fix Apple TV breakage. This should allow scripts/objc-test-tvos.sh to run normally.
Closes https://github.com/facebook/react-native/pull/12565
Differential Revision: D4612182
Pulled By: hramos
fbshipit-source-id: 77fd3eeabc6757b23e4f5efbd46e9948b61b1ab6
Summary:
This decouples non-UI logic from RCTDevMenu into a new module RCTDevSettings.
**Motivation**: This allows developers to change dev settings without depending on the built-in dev menu, e.g. if they want to introduce their own UI, or have other devtools logic that doesn't depend on an action sheet.
It also introduces the RCTDevSettingsDataSource protocol for storing dev tools preferences. This could allow a developer to implement alternative behaviors, e.g. loading the settings from some other config, changing settings based on the user, deciding not to persist some settings, or something else.
The included data source implementation, RCTDevSettingsUserDefaultsDataSource, uses NSUserDefaults and is backwards compatible with the older implementation, so **no workflows or dependent code will break, and old saved settings will persist.**
The RCTDevMenu interface has not changed and is therefore also backwards-compatible, though
some methods are now deprecated.
In order to ensure that RCTDevSettings
Closes https://github.com/facebook/react-native/pull/11613
Reviewed By: mmmulani
Differential Revision: D4571773
Pulled By: javache
fbshipit-source-id: 25555d0a6eaa81f694343e079ed02439e5845fbc
Summary:
This PR will:
- add missing documentation for `caretHidden` prop to the docs
- add `caretHidden` prop implementation for Android
I noticed this by accident when looking at `RCTTextFieldManager.m` and there is `RCT_EXPORT_VIEW_PROPERTY(caretHidden, BOOL)` which hides caret on iOS. Then I realised that the docs were missing for this prop and implementation on Android side :)
Render `TextInput` with prop `caretHidden`. After this caret is not visible anymore.
`<TextInput style={styles.input} caretHidden />`
If you omit the prop then caret is visible again
`<TextInput style={styles.input} />`
Closes https://github.com/facebook/react-native/pull/11863
Differential Revision: D4448402
fbshipit-source-id: 456e1df3e2cbb8af32540d2c7a8f4e7da219f5c3
Summary:
When creating Native UI Component per docs, it results in duplicate symbols error as explained in issue #12404
Instead of using RCT prefix, it is suggested to use RN prefix to avoid any duplicate symbols.
Closes https://github.com/facebook/react-native/pull/12523
Differential Revision: D4608532
Pulled By: hramos
fbshipit-source-id: 353cfee4bf2cea30706863af51cabe11e9394222
Summary:
**Motivation**:
The `CameraRoll.getPhotos()` documentation is lacking, I've simply exposed the shapes of the params object and returned object, as defined and documented in `getPhotosParamChecker` and `getPhotosReturnChecker`.
**Test plan**:
Built the website and checked the documentation.
Closes https://github.com/facebook/react-native/pull/12524
Differential Revision: D4608419
Pulled By: hramos
fbshipit-source-id: 887d32b32312a492e57bf65fca503891de0bd661
Summary:
Just a little nit pick to add extra information to this doc. I spent a few hours trying to fix this problem because I had not placed the code in build.gradle correctly. I think this small addition would be useful to others.
Closes https://github.com/facebook/react-native/pull/12475
Differential Revision: D4608443
Pulled By: hramos
fbshipit-source-id: eb719d5cf9d905c4f043ec71f1a3e28e0219626e
Summary:
I guess we could ask Håkon Wium Lie if indeed it was unintended to have a set of rules be inherited or not, but this paragraph is a little bit weird 🤷♀️
Closes https://github.com/facebook/react-native/pull/12485
Differential Revision: D4608425
Pulled By: hramos
fbshipit-source-id: a346b1e65c9fc7b06634e529c1ef6f9e24794cca
Summary:
> Explain the **motivation** for making this change. What existing problem does the pull request solve?
I was reading the documentation and noticed this broken link.
Closes https://github.com/facebook/react-native/pull/12535
Differential Revision: D4608413
Pulled By: hramos
fbshipit-source-id: 5d3edfaf4e5c16f42a50e203b979b90afe101954
Spencer Ahrens
Valentin Shergin
Eli Perkins
Héctor Ramos
Adam Comella
Andrew Clark
Eric Vicenti
Eloy Durán
Javier Olaechea
Bhuwan Khattar
David Aurelio
Martin Konicek
Christoph Pojer
desmondyao
Swordsman-Inaction
Wietse Venema
Benjamin Dobell
James Isaac
Espen Hovlandsdal
Ashok Menon
Michael Bolin
Eric Vicenti
Gabe Levi
Ryan Florence
Nicholas Tate
Georgiy Kassabli
dlowder-salesforce
Lukas Piatkowski
Cristian Carlesso
Ben Roth
Henrik Raitasola
Victor Choueiri
Mike Griepentrog