Summary: Just cleaning the props for android rendering, similar to iOS
Reviewed By: foghina
Differential Revision: D3735324
fbshipit-source-id: aaf222543701409710a2cd217cc580e79f23bf7b
Summary:
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
> **Unless you are a React Native release maintainer and cherry-picking an *existing* commit into a current release, ensure your pull request is targeting the `master` React Native branch.**
(You can skip this if you're fixing a typo or adding an app to the Showcase.)
Explain the **motivation** for making this change. What existing problem does the pull request solve?
Prefer **small pull requests**. These are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
**Test plan (required)**
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.
Make sure tests pass on both Travis and Circle CI.
**Code formatting**
Look around. Match the style of the rest of the codebase. See also the simple [style guide](https://github.com/face
Closes https://github.com/facebook/react-native/pull/8999
Differential Revision: D3664512
Pulled By: javache
fbshipit-source-id: 030fe4752e53efcde21baadfc2502413b7fc9c8c
Summary:
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
> **Unless you are a React Native release maintainer and cherry-picking an *existing* commit into a current release, ensure your pull request is targeting the `master` React Native branch.**
(You can skip this if you're fixing a typo or adding an app to the Showcase.)
Explain the **motivation** for making this change. What existing problem does the pull request solve?
Prefer **small pull requests**. These are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
**Test plan (required)**
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.
Make sure tests pass on both Travis and Circle CI.
**Code formatting**
Look around. Match the style of the rest of the codebase. See also the simple [style guide](https://github.com/face
Closes https://github.com/facebook/react-native/pull/9141
Differential Revision: D3650195
Pulled By: hramos
fbshipit-source-id: 2a4bb06f92109b36bec761259e13a5782cc9929b
Summary:
On iOS, if `TextInput` is used with prop `multiline={true}`, the backend view is `UITextView`. Sometimes we need `UITextView.dataDetectorTypes` to detect clickable url in the text view. The PR add this prop to `TextInput`, so we can use it like this:
`<TextInput`
` defaultValue="Detect phone number: 88888888."`
` editable={false}`
` multiline={true}`
` dataDetectorTypes="all"`
` />`
Similar as #8743 .
Closes https://github.com/facebook/react-native/pull/8863
Differential Revision: D3648027
fbshipit-source-id: 987bd4f46fb5be74099b62988135a32115d9269c
Summary:
**motivation**
Previously, size can only accept either 'small' or 'large'. And to obtain a custom size, scale transformation is used. This is to let users to possibly pass number value directly to define ActivityIndicator's size.
**Test plan**
I have also modified the current example to reflect the new size prop in action.
Closes https://github.com/facebook/react-native/pull/8935
Differential Revision: D3637910
fbshipit-source-id: 6b8e1d4504964916df327b2d3eaaef1bb8cd5112
Summary:
I noticed that even when a ScrollView's `keyboardShouldPersistTaps` prop is set to true, the ScrollView's children can still respond to tap events (even if the scroll view itself will not respond to tap events and the keyboard does not dismiss automatically). This is a point of ambiguity in the React Native docs; it implies that no touch events can be handled if `keyboardShouldPersistTaps` is set to true.
Closes https://github.com/facebook/react-native/pull/9053
Differential Revision: D3636711
Pulled By: hramos
fbshipit-source-id: 2f0aea86202ab66d5a9174ce8611509dff67e15f
Summary:
Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
> **Unless you are a React Native release maintainer and cherry-picking an *existing* commit into a current release, ensure your pull request is targeting the `master` React Native branch.**
(You can skip this if you're fixing a typo or adding an app to the Showcase.)
Explain the **motivation** for making this change. What existing problem does the pull request solve?
I'm new to React-Native and noticed a broken link in the documentation. It's just a quick fix.
Prefer **small pull requests**. These are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
**Test plan (required)**
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.
Make sure tests pass on both Travis and Circle CI.
**Code formatting**
Look around. Mat
Closes https://github.com/facebook/react-native/pull/8982
Differential Revision: D3612982
fbshipit-source-id: 2996730e51ae7a243697f305cd2ed2eb0d2985a8
Summary:
In Android `RecyclerViewBackedScrollView` didn't provide the `scrollTo` API, however iOS does.
If a ListView was created with `RecyclerViewBackedScrollView` as its `renderScrollComponent`, then calling `scrollTo` wouldn't work.
This diff enables the `scrollTo` API in `RecyclerViewBackedScrollView` on Android.
Reviewed By: dmmiller
Differential Revision: D3605233
fbshipit-source-id: f192053361f45453e5fce3fb6038ab03ac4025af
Summary: Add support for top, bottom, and center layout gravity to ToastAndroid
Reviewed By: AaaChiuuu
Differential Revision: D3590224
fbshipit-source-id: 84dbbcfbe4133f291d62723c5c261acd7b32b46e
Summary:
In Android, `RecyclerViewBackedScrollView` wasn't using `refreshControl` prop.
If a ListView were created with `RecyclerViewBackedScrollView` as its `renderScrollComponent`, then the `refreshControl` wouldn't work.
example:
```js
<ListView
dataSource={this.props.dataSource}
renderRow={this._renderRow.bind(this)}
refreshControl={
<RefreshControl
refreshing={this.props.isRefreshing}
onRefresh={this._onRefresh.bind(this)}
/>
}
renderScrollComponent={props => <RecyclerViewBackedScrollView {...props} />}/>;
```
This works in iOS, since the `RecyclerViewBackedScrollView` just returns an `ScrollView`.
This pull request uses the `refreshControl` to decide whether it should wrap the `NativeAndroidRecyclerView` with an
`AndroidSwipeRefreshLayout` or not.
This fixes the issue #7134.
Closes https://github.com/facebook/react-native/pull/8639
Differential Revision: D3564158
fbshipit-source-id: c10a880ea61cd80b8af789b00be90d46d63eaf9a
Summary:
Just noticed the old syntax was used in the docs.
Closes https://github.com/facebook/react-native/pull/8765
Differential Revision: D3560355
Pulled By: mkonicek
fbshipit-source-id: 13db21a498be205a32921a89058167dd47e1bbdf
Summary:
WebView component detect phone numbers in html as URL links by default. But sometimes we don't want this behavior.
This PR add dataDetectorTypes as a prop of WebView, so one can specify value of this prop as one or more of phoneNumber/link/address/calendarEvent/none/all
This prop maps to UIWebView.dataDetectorTypes
Closes https://github.com/facebook/react-native/pull/8743
Differential Revision: D3556440
fbshipit-source-id: 55f01d2cdd785381f261a9dc931aa9311f0ad1d4
Summary:
This adds proper support for tracking a TextInput content size as discussed in #6552 by adding a new callback that is called every time the content size changes including when first rendering the view.
Some points that are up for discussion are what do we want to do with the onChange callback as I don't see any use left for it now that we can track text change in onChangeText and size changes in onContentSizeChange. Also a bit off topic but should we consider renaming onChangeText to onTextChange to keep the naming more consistent (see [this naming justification](https://twitter.com/notbrent/status/709445076850597888)).
This is split in 2 commits for easier review, one for iOS and one for android.
The iOS implementation simply checks if the content size has changed everytime we update it and fire the callback, the only small issue was that the content size had several different values on initial render so I added a check to not fire events before the layoutSubviews where at this point the value is g
Closes https://github.com/facebook/react-native/pull/8457
Differential Revision: D3528202
Pulled By: dmmiller
fbshipit-source-id: fefe83f10cc5bfde1f5937c48c88b10408e58d9d
Summary: This removes `node_modules/react` from the list of directories that are used for haste module resolutions. Modules required from React are now imported with `require('react/lib/…')`.
Reviewed By: astreet
Differential Revision: D3509863
fbshipit-source-id: 32cd34e2b8496f0a6676dbe6bb1eacc18124c01e
Summary:
Add `phone-pad` as one of cross-platform values to `keyboardType`.
Closes https://github.com/facebook/react-native/pull/8555
Differential Revision: D3515002
Pulled By: JoelMarcey
fbshipit-source-id: 4f30dd72e8e30905a8a5fb90d3f361fb58eb825e
Summary:
**Motivation**
The prop validation was run on every render, even in prod which seems odd to me. This adds a dev check to make sure prod build skips the validation.
**Test plan (required)**
There are no changes to the ui.
Closes https://github.com/facebook/react-native/pull/8499
Differential Revision: D3508805
Pulled By: javache
fbshipit-source-id: 68c6a1224e33997f9df93481426daff790ef5bcd
Summary: Add support inlining images into text inputs. For now this is only available on Android.
Reviewed By: andreicoman11
Differential Revision: D3470805
fbshipit-source-id: 14db05ec4d5af549bf314b903654314f39bf73ea
Summary:
- Make the examples runnable (both copy/paste and with the web player)
- Add a bit more information in props where needed.
Closes https://github.com/facebook/react-native/pull/8392
Differential Revision: D3482747
Pulled By: caabernathy
fbshipit-source-id: 8f2d812efc1efb3f14db45b5c054ce0d5c14f5f5
Summary:
Initial stab at writing a high level guide on navigation. Its main focus is on Navigator due to it being cross-platform and fairly simple to use.
This guide should be expanded to cover tabbed applications in a future pull request.
The Navigation (Experimental) section will be similarly expanded upon as the API stabilizes.
![navigation](https://cloud.githubusercontent.com/assets/165856/16324560/52b508dc-396a-11e6-94b7-b2d1175f69e0.png)
Closes https://github.com/facebook/react-native/pull/8390
Differential Revision: D3480304
Pulled By: caabernathy
fbshipit-source-id: 280da9185fca295bc107a2df20106c783b461be7
Summary:
Two of the known issues have been moved to the issue tracker:
* #8315
* #8316
Others have been moved into more appropriate locations, such as the `TextInput` issue to the API doc itself, and the React debugging issue to the Debugging doc.
The Android-specific compatibility concerns have been dropped entirely as it does not seem like people would find these in the docs.
Closes https://github.com/facebook/react-native/pull/8321
Differential Revision: D3477999
Pulled By: JoelMarcey
fbshipit-source-id: dfffc9910ebf5514eb14c6aa8a9a3e70761db874
Summary:
If using colors that are not strings react native would warn you of the problem. I made some changes so color props use `ColorPropType` instead of `PropTypes.string`.
Closes https://github.com/facebook/react-native/pull/8325
Differential Revision: D3475516
Pulled By: javache
fbshipit-source-id: b7e40a0de5e665fc5f41a975650bbba0ec210814
Summary:
Ensure all `props` have documentation. Add more details to current `props`.
Provide more information to the API in general.
> Would like to try to integrate the React Native Web Player for the initial
> example, but not right now.
Closes https://github.com/facebook/react-native/pull/8341
Differential Revision: D3475105
Pulled By: caabernathy
fbshipit-source-id: 00ad30b2359831740715517278bec1d0231e089d
Summary:
As part of improving the API and Component reference docs #8154 this pull request adds the following:
- jsdoc support for API docs. See the AlertIOS changes as an example.
- type definitions support and added to both API and Component docs. This is supported via react-docgen and jsdoc.
- better formatting of method properties (now shown in a table).
FYI, API and Component docs were previously generated in two different ways. Components were using react-docgen and that basically remains as-is. APIs were using custom parsing code and that's been switched to use a jsdoc parser + react-docgen as an option for typedefs (it could also use the jsdoc parser).
Two docs have been updated to showcase how we'd like the new docs to look:
- AlertIOS (API): showing method parameters, examples, typedefs, more details overall.
- Statusbar (Component): showing method parameters, typedefs, more details overall.
**Note**: To convert new API docs to use the new format, add `jsdoc` to the initial file comment. C
Closes https://github.com/facebook/react-native/pull/8196
Differential Revision: D3465037
Pulled By: lacker
fbshipit-source-id: 78415d44bc5be02db802f5b1f7a0b249689abdf7
Summary:
With accessibility prop set to true, it is not possible to access
childern elements. This makes it impossible to test Components with
appium and releatives. This commit adds support to change accessiblity
property on Touchable elements to overcome the aforementioned issue.
Closes https://github.com/facebook/react-native/pull/8243
Differential Revision: D3462949
Pulled By: javache
fbshipit-source-id: 65ce6507a1619218ab5b527c970a74af197ef462
Summary:
This replaces ActivityIndicatorIOS and indeterminate ProgressBar that were deprecated recently with ActivityIndicator across the codebase and examples and a few other cleanups.
This also make a small tweak to ActivityIndicator so it uses the Android theme color instead of gray when no color is specified.
Use Slider instead of SliderIOS in CameraRoll example.
Remove the line about unifying ActivityIndicator and ProgressBar.
**Test plan**
Tested the affected components in UIExplorer on iOS and Android, tested the changes made in Movies example on iOS and Android.
Closes https://github.com/facebook/react-native/pull/8082
Differential Revision: D3429770
fbshipit-source-id: 3b2e1196a8b9fe00d47a7aa1bbc079b094796421
Summary: ImageCropper is broken on iOS. Can not scroll up and down
Differential Revision: D3413397
fbshipit-source-id: 75096fc1d5dd14764c0ddd4fd3888a9576c1d1ce
Summary:
KeyboardAvoidingView is a component we built internally to solve the common problem of views that need to move out of the way of the virtual keyboard.
KeyboardAvoidingView can automatically adjust either its position or bottom padding based on the position of the keyboard.
Reviewed By: javache
Differential Revision: D3398238
fbshipit-source-id: 493f2d2dec76667996250c011a1c5b7a14f245eb
Summary:
Reduce the public surface area of TextInput. It only exposes a secureTextEntry property, but on Android was also accepting password as a prop.
This removes that.
Reviewed By: javache
Differential Revision: D3392223
fbshipit-source-id: 67c36fbe16fe493e2841d5d9deb78e3be2209ebd
Summary:
The propTypes of RCTDatePickerIOS do not fit with the propTypes of DatePickerIOS.
All dates (date, minimumDate, maximumDate) are a timestamp (check line 126), so they should have propType number.
OnDateChange function should not be required since it is called onChange in the iOS implementation.
The problem currently causes warnings that the given types are wrong, while they were added correctly.
Closes https://github.com/facebook/react-native/pull/7833
Differential Revision: D3371324
Pulled By: nicklockwood
fbshipit-source-id: bca5b2bbe7e9dd2e045288bfbd268578848c7bff
Summary: The DatePicker had a hard-coded width of 320 for no reason I can think of. Removing it allows the DatePicker to naturally scale to fit the width of the container, which is how the regular Picker works already.
Reviewed By: lexs
Differential Revision: D3371355
fbshipit-source-id: e06d31f7275de41bb00226232cf47ad022d25b4d
Summary:
The API for `ActivityIndiatorIOS` and `ProgressBarAndroid` is very similar and can be merged in a cross platform component that displays a circular indeterminate loading indicator.
This deprecates `ActivityIndiatorIOS` and non-horizontal `ProgressBarAndroid` in favor of this new component.
**Test plan (required)**
Tested with the ActivityIndicator example in UIExplorer on android and ios. Also made sure that `ActivityIndicatorIOS` still works and displays a deprecation warning. Also tested that `ProgressBarAndroid` with `indeterminate == true` and `styleAttr != 'Horizontal'` displays a deprecation warning.
Closes https://github.com/facebook/react-native/pull/6897
Differential Revision: D3351607
Pulled By: dmmiller
fbshipit-source-id: b107ce99d966359003e8b3118cd97b90fa1d3d7d
Summary:
Autocorrect was broken for controlled TextInput components by a change to batch event handling in React Native:
9f11f8c263
For example, a TextInput like this would be affected by this bug:
```javascript
<TextInput
autoCorrect={true}
style={{height: 26, width: 100}}
onChangeText={(text) => this.setState({ text })}
value={this.state.text}
/>
```
This fix uses the same approach as
0cd2904b23
The problem is that TextInput's _onChange handler relied on this.props.value being updated synchronously when calling this.props.onChangeText(text). However, this assumption was broken when React Native event handling started being batched.
The fix is to move the code that relies on this.props.value being up-to-date to componentDidUpdate.
**Test plan (required)**
Tested autocorrect now works on iOS in a small app and a large app. Also tested t
Closes https://github.com/facebook/react-native/pull/7676
Differential Revision: D3346221
Pulled By: nicklockwood
fbshipit-source-id: 715df3e8a03aa58cb0a462de4add02289d42782f
Summary:
Removes the deprecated APIs that were replaced by `RefreshControl`. Those API have been deprecated for a while already so I think it's fine to remove them at this point. Also ported the `SwipeRefreshLayoutTestModule` test to use `RefreshControl` instead of `PullToRefreshViewAndroid`.
**Test plan (required)**
Made sure no references are left in the codebase to `PullToRefreshViewAndroid`, `onRefreshStart` and `endRefreshing`.
Tested that `ScrollView` examples in UIExplorer still work properly.
Check that the `SwipeRefreshLayoutTestModule` passes on CI.
Closes https://github.com/facebook/react-native/pull/7447
Reviewed By: mkonicek
Differential Revision: D3292391
Pulled By: bestander
fbshipit-source-id: 27eb2443861e04a9f7319586ce2ada381b714d47
Summary:
The default itemPositioning is `automatic` (referred to `auto` in this pull request) - you can check its behaviour in the docs attached.
Sometimes that value has to be modified to have more predictable appearance as described in #4136.
Closes https://github.com/facebook/react-native/pull/7217
Differential Revision: D3220958
Pulled By: mkonicek
fbshipit-source-id: d4bf648b16e71825cd31c06d6b6396479767d19f
Summary:
We want to give people the ability to log scroll performance (including Fb).
This adds an interface that can be enabled and disabled from the react scroll views.
This is a prerequisite to implementing the actual framerate logger that will log dropped
frames while scrolling in prod.
Reviewed By: astreet
Differential Revision: D3283588
fbshipit-source-id: ed9736cb9ed3f441511647f36b1460092bd91e56
Summary:
This is a nice feature to have.
I've tested this by copying and renaming the ViewPager java and javascript files from the react-native repo and including them in a project. Whats the best way to test this directly from the repo?
Closes https://github.com/facebook/react-native/pull/5968
Differential Revision: D3240651
Pulled By: mkonicek
fbshipit-source-id: 5f1d157216df4f3314915496188a92aec1b85e91
Summary:
This is a solution for the problem I raised in https://www.facebook.com/groups/react.native.community/permalink/768218933313687/
I've added a new native base class, `RCTEventEmitter` as well as an equivalent JS class/module `NativeEventEmitter` (RCTEventEmitter.js and EventEmitter.js were taken already).
Instead of arbitrary modules sending events via `bridge.eventDispatcher`, the idea is that any module that sends events should now subclass `RCTEventEmitter`, and provide an equivalent JS module that subclasses `NativeEventEmitter`.
JS code that wants to observe the events should now observe it via the specific JS module rather than via `RCTDeviceEventEmitter` directly. e.g. to observer a keyboard event, instead of writing:
const RCTDeviceEventEmitter = require('RCTDeviceEventEmitter');
RCTDeviceEventEmitter.addListener('keyboardWillShow', (event) => { ... });
You'd now write:
const Keyboard = require('Keyboard');
Keyboard.addListener('keyboardWillShow', (event) => { ... });
Within a component, you can also use the `Subscribable.Mixin` as you would previously, but instead of:
this.addListenerOn(RCTDeviceEventEmitter, 'keyboardWillShow', ...);
Write:
this.addListenerOn(Keyboard, 'keyboardWillShow', ...);
This approach allows the native `RCTKeyboardObserver` module to be created lazily the first time a listener is added, and to stop sending events when the last listener is removed. It also allows us to validate that the event strings being observed and omitted match the supported events for that module.
As a proof-of-concept, I've converted the `RCTStatusBarManager` and `RCTKeyboardObserver` modules to use the new system. I'll convert the rest in a follow up diff.
For now, the new `NativeEventEmitter` JS module wraps the `RCTDeviceEventEmitter` JS module, and just uses the native `RCTEventEmitter` module for bookkeeping. This allows for full backwards compatibility (code that is observing the event via `RCTDeviceEventEmitter` instead of the specific module will still work as expected, albeit with a warning). Once all legacy calls have been removed, this could be refactored to something more elegant internally, whilst maintaining the same public interface.
Note: currently, all device events still share a single global namespace, since they're really all registered on the same emitter instance internally. We should move away from that as soon as possible because it's not intuitive and will likely lead to strange bugs if people add generic events such as "onChange" or "onError" to their modules (which is common practice for components, where it's not a problem).
Reviewed By: javache
Differential Revision: D3269966
fbshipit-source-id: 1412daba850cd373020e1086673ba38ef9193050
Summary:
- getScrollResponder returns a...ScrollView!
- no more var
- no more string refs
Reviewed By: spicyj
Differential Revision: D3286596
fbshipit-source-id: d9e6e0a318eadd2521c9f5c69d2ec368f1d7b626
Summary:
React.PropTypes.oneOf accepts array as parameter, non-array given. this make the app throw a warning.
Closes https://github.com/facebook/react-native/pull/7498
Differential Revision: D3285737
fbshipit-source-id: 3d86b4b36d696e054f9225d7e3a9eddf91477813
Summary: Move all requires of UIManager to UIManager.js, so we can load the view manager configuration lazily when UIManager is required.
Reviewed By: majak
Differential Revision: D3270147
fb-gh-sync-id: 8208ee8d5919102ea5345e7031af47ee78162fe0
fbshipit-source-id: 8208ee8d5919102ea5345e7031af47ee78162fe0
Summary:
Add the possibility to define a progress view top offset to RefreshControl on android. As i comment in #6740, contentInset does the trick on IOS.
Looking android documentation seems that exists a possible solution:
http://developer.android.com/reference/android/support/v4/widget/SwipeRefreshLayout.html#setProgressViewOffset(boolean, int, int)
This pull request implement that but keeping it simple, only a top offset.
For example, now we could put navigation bar over the scrollview (or listview) and define a progressViewOffset on RefreshView in order to start behind the navigation. At this point we could make some kind of coordinator layout to hide/show navigation on scroll.
To maintain the default behavior, start point is equal to start point minus progress circle diameter in order to create that progress circle before the start point.
Closes https://github.com/facebook/react-native/pull/6759
Differential Revision: D3240664
Pulled By: mkonicek
fb-gh-sync-id: ccf866272e871811c1c6dcc2a34f5c217967feee
fbshipit-source-id: ccf866272e871811c1c6dcc2a34f5c217967feee
Summary:
There was an issue with the way we made `RefreshControl` a controlled component when react doesn't render synchronously. This fixes the issue by using the same technique used in the commit 0cd2904b23 for`PickerAndroid`
**Test plan (required)**
Tested normal behaviour and tested that if not setting the `refreshing` prop to `true` during the `onRefresh` callback that the `RefreshControl` stops refreshing immediately. Also made sure that `setNativeProps` is only called if needed when the native refreshing state is not in sync with JS.
Fix#7414
Closes https://github.com/facebook/react-native/pull/7445
Differential Revision: D3274981
fb-gh-sync-id: a1b9d46329f552984e33d11fa0e29ad6da689511
fbshipit-source-id: a1b9d46329f552984e33d11fa0e29ad6da689511
Summary:
Previously, the back swipe navigation gesture would be enabled when the navigation bar is shown and disabled when the navigation bar is hidden.
This change enables developers to control the back swipe gesture independently of the visibility of the navigation bar. An example use case would be that an app wants to render a custom navigation bar so it sets `navigationBarHidden` to true and it wants to enable the back swipe gesture so it sets `interactivePopGestureEnabled` to true.
**Test plan (required)**
- Created a test app to verify setting `interactivePopGestureEnabled` to `true` and `false` with the navigation bar both hidden and shown.
- Verified prop works in a larger app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/7369
Differential Revision: D3269304
Pulled By: javache
fb-gh-sync-id: ec4324f6517cec4b4fc4f62c4394dc9208a8af6a
fbshipit-source-id: ec4324f6517cec4b4fc4f62c4394dc9208a8af6a
Summary:
This adds support for pagingEnabled to the HorizontalScrollView.
This is an initial implementation.
Because Android doesn't provide great details about what is happening with a scroll view after you are done touching it, we have some post touch handling. This is kicked off either by touch up or a fling call.
Once we are doing that handling, we start a runnable that basically checks if we are still scrolling. If we are, we just schedule that runnable again and check a frame later. If we are done scrolling (no onScrollChanged since we last fired), we could be in one of two states, the fling is done or we are done snapping to the page boundary. If we are in the fling done case, we then check if we need to scroll to a page boundary. If so, we call smoothScrollTo and schedule ourself to check onScroll events again until done with that scroll. If we are done with both (either we only did momentum scroll or we did that and then snapped to page), we can then fire the final event and stop checking. This logic is all in handlePostTouchScrolling.
Because of the decision to only do page scrolling after momentum ends, we do allow you to scroll through with momentum a number of pages and the transition can be a little strange where it stops a sec and then slides to be page aligned. As a follow up, we can probably smooth that up by changing the value we pass to super.fling() that would adjust it to be let momentum carry it to the page boundary.
Reviewed By: weicool
Differential Revision: D3207608
fb-gh-sync-id: 02f62970ed9a5e3a5f9c0d959402756bc4b3699e
fbshipit-source-id: 02f62970ed9a5e3a5f9c0d959402756bc4b3699e
Summary:
Hi,
This PR Solves this issue #3083.
This PR solves the problem of default color on TabBar being always grey. Which looks great if the barTintColor is unchanged. However if we set the barTintColor to something else (like blue in example) text and icons become quite unreadable.
![simulator screen shot 27 apr 2016 21 58 40](https://cloud.githubusercontent.com/assets/12081272/14866402/e51c7120-0cc3-11e6-9570-097b686c160f.png)
Commit (c206417) - Enable setting color of unselected tabs
Solves this issue with a prop (unselectedTintColor) on TabBarIOS to which you just pass a color like you can for barTintColor and tintColor.
This leaves us with a result that is on second picture. Notice the color of text on tabs.
![simulator screen shot 27 apr 2016 21 59 06](https://cloud.githubusercontent.com/assets/12081272/14866419/f77aa7e2-0cc3-11e6-8c90-33209009bc09.png)
Or change it to yellow for demonstrating purposes
![simulator screen shot 27 apr 2016 21 59 13](https://cloud.githubusercontent.com/assets/1208
Closes https://github.com/facebook/react-native/pull/7264
Differential Revision: D3240924
Pulled By: nicklockwood
fb-gh-sync-id: 14a0de28abd064756320b7a74f128c255caa6b12
fbshipit-source-id: 14a0de28abd064756320b7a74f128c255caa6b12
Summary:
Just showing a hash of values is misleading. Makes the user think you can just pass in the values without the keys.
Closes https://github.com/facebook/react-native/pull/7310
Differential Revision: D3245834
fb-gh-sync-id: 39220ed7720e3ff402f2c2ba8bebdefb96bfa203
fbshipit-source-id: 39220ed7720e3ff402f2c2ba8bebdefb96bfa203
Summary:
I had to do a little trial and error to find this out. Would be helpful to have it in the docs.
I'm not sure if there's a standard wording or format you prefer for indicating handler function params.
Closes https://github.com/facebook/react-native/pull/7312
Differential Revision: D3245838
fb-gh-sync-id: 89433c036f7287d9efb69605180734dbc4df4df3
fbshipit-source-id: 89433c036f7287d9efb69605180734dbc4df4df3
Summary:
Useful to know what the default value without having to dig into the library code.
Closes https://github.com/facebook/react-native/pull/7247
Differential Revision: D3228728
Pulled By: mkonicek
fb-gh-sync-id: 433ca41d5395bbfb0c4887641a9e8b99c87b5e2b
fbshipit-source-id: 433ca41d5395bbfb0c4887641a9e8b99c87b5e2b
Summary: Using customDirectEventTypes or customBubblingEventTypes causes a viewmanager to be initialized at app start. This diff deprecates those methods and removes their usage from RCTScrollViewManager.
Reviewed By: majak
Differential Revision: D3218973
fb-gh-sync-id: 295bef3be9623b49b0cdcbf8a56e10d9b28126d9
fbshipit-source-id: 295bef3be9623b49b0cdcbf8a56e10d9b28126d9
Summary: Creating a view instance just to get the default view size is quite expensive, and affects startup time for the bridge as it must be done on the main thread. I've removed these cases and simply hard-coded the sizes in the JS file. This will need to be updated if the view sizes ever change, but in practice that's very unlikely.
Reviewed By: javache
Differential Revision: D3218917
fb-gh-sync-id: 91a21dabb6046c5d4d5d0bec0845415cb3628ec3
fbshipit-source-id: 91a21dabb6046c5d4d5d0bec0845415cb3628ec3
Summary:Using TouchableNativeFeedback has been a problem for me because the ripples it makes don't follow the child view's border radii so the ripples stick out of the child view's rounded corners. This PR should fix this problem with a minor caveat: this only works for TouchableNativeFeedback.Ripple and not TouchableNativeFeedback.SelectableBackground. I searched how I could apply corner radius to selectableItemBackground and it doesn't seem to be possible (the prevalent advice is to create the ripple manually which is equivalent to using TNF.Ripple in our case), though I could be wrong.
I added [an example to UIExplorer (TouchableExample)](http://i.imgur.com/CHY9xjW.png). This is my first PR to this repo so let me know if something's wrong. Cheers!
Closes https://github.com/facebook/react-native/pull/6515
Differential Revision: D3126513
Pulled By: AaaChiuuu
fb-gh-sync-id: 4a00e7177ee4ffd8dffeca143f4f43f08c99b5a1
fbshipit-source-id: 4a00e7177ee4ffd8dffeca143f4f43f08c99b5a1
Summary:Using TouchableNativeFeedback has been a problem for me because the ripples it makes don't follow the child view's border radii so the ripples stick out of the child view's rounded corners. This PR should fix this problem with a minor caveat: this only works for TouchableNativeFeedback.Ripple and not TouchableNativeFeedback.SelectableBackground. I searched how I could apply corner radius to selectableItemBackground and it doesn't seem to be possible (the prevalent advice is to create the ripple manually which is equivalent to using TNF.Ripple in our case), though I could be wrong.
I added [an example to UIExplorer (TouchableExample)](http://i.imgur.com/CHY9xjW.png). This is my first PR to this repo so let me know if something's wrong. Cheers!
Closes https://github.com/facebook/react-native/pull/6515
Differential Revision: D3126513
Pulled By: mkonicek
fb-gh-sync-id: 1d3e92243abf9706132ae47c485d9e04a9b47d81
fbshipit-source-id: 1d3e92243abf9706132ae47c485d9e04a9b47d81
Summary:**Motivation:** In my app, I'm using a WebView that loads content from my mobile site. What I want to do is when a user presses a link on the loaded page, I want to stop the WebView's request, hijack the URL and open the URL in a new WebView, pushed to the top of the navigator stack. To me, this gives the overall app a more native feel, instead of implementing a rudimentary navbar on the main WebView to go back.
**Attempted Workarounds:** I've attempted to get similar functionality by capturing the onNavigationStateChange event in the WebView, and then within calling goBack + pushing the new view to the navigator stack. From a functionality standpoint, this works. However, from a UI standpoint, the user can clearly see the webview change states to a new page + go back before having the new view pushed on top of their nav stack.
Closes https://github.com/facebook/react-native/pull/6886
Differential Revision: D3212447
Pulled By: mkonicek
fb-gh-sync-id: 05911e583d9ba54ddbd54a772153c80ed227731e
fbshipit-source-id: 05911e583d9ba54ddbd54a772153c80ed227731e
Summary: Similar to ScrollView, adds ability to set scrollEnabled={false}, which prevents dragging. Paging is still possible by updating initialPage.
Reviewed By: AaaChiuuu
Differential Revision: D3209743
fb-gh-sync-id: ce4140323a03f2257a9bb310c7285418b01abae7
fbshipit-source-id: ce4140323a03f2257a9bb310c7285418b01abae7
Summary:This fixes autocomplete for CJK text input by making sure that the `<Text>` nodes that JS controls to produce attributed text matches the text view's attributed text as much as possible. This is done by giving the disconnected `<Text>` child the same style as the `<TextInput>` parent.
This works because `-[RKTextView performPendingTextUpdate]` avoids setting the attributedText property on textView if the JS attributedText and textView attributedText are equal. This is important because setting attributedText on a text view clears the autocomplete state (markedText property) on a text view, breaking autocomplete for multistage input styles like CJK with a phonetic keyboard.
Reviewed By: nicklockwood
Differential Revision: D3207513
fb-gh-sync-id: 02e582ea5f15191974f15a65ebc1820401715f8d
fbshipit-source-id: 02e582ea5f15191974f15a65ebc1820401715f8d
Summary:Adding the react native renderer dependency and various fixes to support React 15.
Don't use dispatchID for touchableHandleResponderGrant
This callback argument was removed because "IDs" no longer exist. Instead, we'll
use the tag from the event target.
The corresponding PR on React Core is: https://github.com/facebook/react/pull/6338
Reviewed By: spicyj
Differential Revision: D3159788
fb-gh-sync-id: 60e5cd2aa0af69d83fcdac3dfde0a85a748cb7b9
fbshipit-source-id: 60e5cd2aa0af69d83fcdac3dfde0a85a748cb7b9
Summary:Hi there,
This PR reorganises the flow for updating native props so that if you have a switch that's replaced with a spinner to handle a network action, you don't get a crash trying to update native props when an item may be moved out from underneath you. This was previously accepted but I had to rebase it so I just recreated it given it was a two line fix
Closes https://github.com/facebook/react-native/pull/6989
Differential Revision: D3190326
fb-gh-sync-id: 357ffb36bb31bd23970e4ab396fc29a49ec18e1c
fbshipit-source-id: 357ffb36bb31bd23970e4ab396fc29a49ec18e1c
Summary:Set `Touchable.TOUCH_TARGET_DEBUG` to see colored borders/text to all touchables.
Different touchable types are color-coded differently.
If there is `hitSlop`, it will be rendered with an extra view with a dashed border of the same color (not visible on
Android because `overflow: 'hidden'`).
`Text` with `onPress` directly set is just colored.
Added some extra checks to `TouchableWithoutFeedback` since it could silently break if the child is not a native
component.
Also added better error output for `ensureComponentIsNative` so it's easier to track down issues. I really wish there
was a cleaner way to get the component and owner names consistently, it would help make good debug messages way easier
to write.
Reviewed By: ericvicenti
Differential Revision: D3149865
fb-gh-sync-id: 602fc3474ae7636e32af529eb7ac52ac5b858030
fbshipit-source-id: 602fc3474ae7636e32af529eb7ac52ac5b858030
Summary:Unmounting the RefreshControl during onRefresh callback causes the native ref to become null, this simply adds a null check to prevent the crash.
Closes https://github.com/facebook/react-native/pull/6931
Differential Revision: D3167637
fb-gh-sync-id: c2420b7a3b672d62dd349a6d35bb05399a00620c
fbshipit-source-id: c2420b7a3b672d62dd349a6d35bb05399a00620c
Summary:The website now displays public methods on components. This was implemented mostly in react-docgen via #66. This adds a <Method> component that is used by the component and API doc pages to display documentation for a method.
It also adds some missing documentation and tweak some existing one to integrate with this feature. I also prefixed some component methods with an '_' so they don't show up in the doc.
**Test plan (required)**
Tested every component page locally to make sure the methods doc was displayed properly.
Tested an API page to make sure it still worked properly.
Closes https://github.com/facebook/react-native/pull/6890
Differential Revision: D3159911
Pulled By: vjeux
fb-gh-sync-id: 1e6a4640cda6794496d9844c1af6a1451c017dcc
fbshipit-source-id: 1e6a4640cda6794496d9844c1af6a1451c017dcc
Summary:Since the React 0.14 split of modules, the findNodeHandle feature is part of the
renderer and not the generic React API.
This just greps for React.findNodeHandle and replace them with ReactNative.findNodeHandle. I fixed up the imports manually.
I also found two callers each of ReactNative.createClass and React.render with the exception of downstream and examples will fix them separately.
I'll need to find more things like `var { PropTypes } = ReactNative;` separately. I think this is a good start though.
Reviewed By: vjeux
Differential Revision: D3149356
fb-gh-sync-id: 50ed60bc67270b16f561d4c641f2f19e85724d3b
fbshipit-source-id: 50ed60bc67270b16f561d4c641f2f19e85724d3b
Summary:Remove Trailing Spaces.
Why:
Sometimes there are conflicts with trailing spaces
Saves space
Those whose tools automatically delete them will have their pr watered down with trailing space removal
Closes https://github.com/facebook/react-native/pull/6787
Differential Revision: D3144704
fb-gh-sync-id: d8a62f115a3f8a8a49d5b07f56c540a02af38cf8
fbshipit-source-id: d8a62f115a3f8a8a49d5b07f56c540a02af38cf8
Summary:This fixes issues with other view (like the Navigator) stealing the responder and becoming interactive while the user is dragging the slider.
From [documentation](https://facebook.github.io/react-native/docs/gesture-responder-system.html):
- `onStartShouldSetResponder`: Does this view want to become responder on the start of a touch? -> Yes.
- `onResponderTerminationRequest`: Something else wants to become responder. Should this view release the responder? -> No.
Reviewed By: ericvicenti
Differential Revision: D3133337
fb-gh-sync-id: 3d7e1e6a2ed6fa605857cfb0549ffa71df85fd22
fbshipit-source-id: 3d7e1e6a2ed6fa605857cfb0549ffa71df85fd22
Summary:The navigation drawer of most apps on android opens over the status bar, this adds an option to do so. It implements a similar API to the native DrawerLayout by adding a statusBarBackgroundColor to DrawerLayoutAndroid.
Without statusBarBackgroundColor:
![image](https://cloud.githubusercontent.com/assets/2677334/13414490/50ebcdf4-df21-11e5-974f-c6a1343c2a4e.png)
With statusBarBackgroundColor:
![image](https://cloud.githubusercontent.com/assets/2677334/13414459/1fdc4086-df21-11e5-9658-bd47bfdb925f.png)
This PR depends on the changes in #6195 to add the `StatusBar.HEIGHT` constant I just want to put it out there now to see if this looks good. To test without the other PR just change `StatusBar.HEIGHT` for `25`.
It is implemented by making the native status bar translucent and making its background color transparent so we can draw a view of the same height as the status bar under it as a child of the DrawerLayoutAndroid. Then we can draw a semi-transparent gray View inside the drawer view to make it
Closes https://github.com/facebook/react-native/pull/6218
Differential Revision: D3017444
Pulled By: bestander
fb-gh-sync-id: ca48a47a20a2feecae360a76f3e2c9bbe6a37700
fbshipit-source-id: ca48a47a20a2feecae360a76f3e2c9bbe6a37700
Summary:Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
(You can skip this if you're fixing a typo or adding an app to the Showcase.)
Explain the **motivation** for making this change. What existing problem does the pull request solve?
Prefer **small pull requests**. These are much easier to review and more likely to get merged. Make sure the PR does only one thing, otherwise please split it.
**Test plan (required)**
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.
Make sure tests pass on both Travis and Circle CI.
**Code formatting**
Look around. Match the style of the rest of the codebase. See also the simple [style guide](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#style-guide).
Closes https://github.com/facebook/react-native/pull/6706
Differential Revision: D3109403
fb-gh-sync-id: 4c92b4dc7950377f9efad6129a49c594bcd9a68a
fbshipit-source-id: 4c92b4dc7950377f9efad6129a49c594bcd9a68a
Summary: Minor improvements to the <Switch> docblock, including adding some keywords to make it easier to find. Also, I updated documentation for the deprecated platform-specific versions of the component.
Reviewed By: jingc
Differential Revision: D3098626
fb-gh-sync-id: 86d0f1a45eb8ac1bd9e58ac4ba9c73a4a3dfa846
fbshipit-source-id: 86d0f1a45eb8ac1bd9e58ac4ba9c73a4a3dfa846
Summary:Fix bad wording in the docs change I did in #6534
cc mkonicek
Closes https://github.com/facebook/react-native/pull/6598
Differential Revision: D3085957
Pulled By: vjeux
fb-gh-sync-id: 2b45ac72acf089be6cf8e815aac430a2ce9d08ed
shipit-source-id: 2b45ac72acf089be6cf8e815aac430a2ce9d08ed
Summary: This property is only used by the native code as an optimization to not send events that no one is listening to. We don't need to expose it externally on the js api. Set sendMomentumEvent to be a native only property.
Reviewed By: bestander
Differential Revision: D3092650
fb-gh-sync-id: 95f5f0ae4cd04a7d1cbc9cf17c93647d3c644878
shipit-source-id: 95f5f0ae4cd04a7d1cbc9cf17c93647d3c644878
Summary: I see dead code
Reviewed By: bestander
Differential Revision: D3092668
fb-gh-sync-id: d80a0267aafd856b63e1d2ff1ae8b8e9f6deb8ce
shipit-source-id: d80a0267aafd856b63e1d2ff1ae8b8e9f6deb8ce
Summary:It didn't work for a few reason. First, the drawer view NEEDS to have a background color or no shadow will ever render. Second, we need to use the `setDrawerElevation` method instead of `setElevation` for DrawerLayout. Finally we need to actually pass the style value (maybe we could just pass elevation but I don't really think it can cause any issues) down to the native component as it is not the case at the moment.
I also added a default style to elevation of 16 which is the standard for material design according to https://www.google.com/design/spec/patterns/navigation-drawer.html#navigation-drawer-specs. I could also default it to 0 so it keeps the same appearance as before but I think it looks better this way.
Closes#6022
**Test plan**
Tested using the DrawerLayout in the UIExplorer app.
Before, elevation 0
<img width="420" alt="screen shot 2016-02-23 at 1 55 42 am" src="https://cloud.githubusercontent.com/assets/2677334/13244000/008afdb2-d9d1-11e5-95b8-9c345ea0ea8d.png">
After, elevation
Closes https://github.com/facebook/react-native/pull/6100
Reviewed By: bestander
Differential Revision: D3012242
Pulled By: lexs
fb-gh-sync-id: 4967d7ec920f0229d823032ba95c8a3cace329c6
shipit-source-id: 4967d7ec920f0229d823032ba95c8a3cace329c6
Summary:Updating the comments to clarify that the selectedIndex prop is not just for pre-selecting an index, but that it can also be used to programmatically change the value of the selected index.
Closes https://github.com/facebook/react-native/pull/6519
Differential Revision: D3075199
Pulled By: mkonicek
fb-gh-sync-id: 8ce336ad491bb2fed13df15ebddb1b24535c50ff
shipit-source-id: 8ce336ad491bb2fed13df15ebddb1b24535c50ff
Summary:The docs for touchEvents was really unclear and assumed that you know what `pointer-events` does in CSS. This is confusing especially for native developers, see [this issue](http://stackoverflow.com/questions/36068392/set-userinteractionenabled-false-in-react-native/36096413) on stack overflow.
I added a short description to the prop and all the possible enum values and made it so the comment that explain why it is a prop and not a style doesn't appear on the website as it is not really relevant there.
**Test plan (required)**
Tested by running the website locally.
Closes https://github.com/facebook/react-native/pull/6534
Differential Revision: D3075198
Pulled By: mkonicek
fb-gh-sync-id: 57c8444fc83a31599dc872c361b142531cdd4885
shipit-source-id: 57c8444fc83a31599dc872c361b142531cdd4885
Summary:The docs indicated that a higher number was more accurate, however based on the implementation:
```
/**
* TODO: this logic looks wrong, and it may be because it is. Currently, if _scrollEventThrottle
* is set to zero (the default), the "didScroll" event is only sent once per scroll, instead of repeatedly
* while scrolling as expected. However, if you "fix" that bug, ScrollView will generate repeated
* warnings, and behave strangely (ListView works fine however), so don't fix it unless you fix that too!
*/
if (_allowNextScrollNoMatterWhat ||
(_scrollEventThrottle > 0 && _scrollEventThrottle < (now - _lastScrollDispatchTime)))
```
https://github.com/facebook/react-native/blob/master/React/Views/RCTScrollView.m#L564
It appears that only 0 is a special case here, and perhaps a known issue ;)
Closes https://github.com/facebook/react-native/pull/3729
Differential Revision: D3074801
Pulled By: mkonicek
fb-gh-sync-id: f63b00755f7565165cc628085efa5ed96badcfe1
shipit-source-id: f63b00755f7565165cc628085efa5ed96badcfe1
Summary:This adds a `HEIGHT` constant on `StatusBar` on Android. I needed only this for now but I will work on a better status bar dimensions API later (see TODO).
It also improves the implementation to fix a bug that happened when multiple `StatusBar` components get updated in the same frame as well as remove useless calls to the `StatusBarModule` when values did not change.
Instead of calling the `StatusBarManager` immediately when the component gets updated and relying on the order of the calls that get dispatched to native we now wait at the end of the frame to send the calls to the `StatusBarManager` using `setImmediate`. To make this work properly we need to change the data structure of the props stack a little bit to store the desired transition/animation too for each value.
Finally this updates the example to only show the ones that work for the current platform.
**Test plan**
In the UIExplorer Example, in the 'StatusBar dimensions' section it should show 25 for the height of the status bar.
A
Closes https://github.com/facebook/react-native/pull/6195
Differential Revision: D3017559
fb-gh-sync-id: d6f4c6a72a2dfde83496ecc0f56dca4abaf3055e
shipit-source-id: d6f4c6a72a2dfde83496ecc0f56dca4abaf3055e
Summary:Just added a pass through to the `WebView` for `mediaPlaybackRequiresUserAction` and `setMediaPlaybackRequiresUserGesture` to allow auto-playing audio and video elements
Closes https://github.com/facebook/react-native/pull/5956
Differential Revision: D3053554
Pulled By: mkonicek
fb-gh-sync-id: a1f362c1551de1a0218f5d23c70668e4c8078993
shipit-source-id: a1f362c1551de1a0218f5d23c70668e4c8078993
Summary:Fixes bug https://github.com/facebook/react-native/issues/5604 ("Redscreen error when TouchRelease triggered on a component no longer in the tree")
( maybe not ideally )
This issue is triggered by the following:
A Touch event on a component ( Keep Pressing )
A state/props update removes the component from the tree and render is performed
A Touch Release event. ( When you release the press on the component no longer there )
This fix adds an early return to the signal handling code if a RESPONDER_RELEASE signal happens when the responder has disappeared
Closes https://github.com/facebook/react-native/pull/5637
Differential Revision: D3053729
Pulled By: sahrens
fb-gh-sync-id: 21a2a303d8921654607eaab824ef28fc16df9500
shipit-source-id: 21a2a303d8921654607eaab824ef28fc16df9500
Summary:Thanks for submitting a pull request! Please provide enough information so that others can review your pull request:
(You can skip this if you're fixing a typo or adding an app to the Showcase.)
Explain the **motivation** for making this change. What existing problem does the pull request solve?
Example: When "Adding a function to do X", explain why it is necessary to have a way to do X.
**Test plan (required)**
Demonstrate the code is solid. Example: The exact commands you ran and their output, screenshots / videos if the pull request changes UI.
Make sure tests pass on both Travis and Circle CI.
**Code formatting**
See the simple [style guide](https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md#style-guide).
Closes https://github.com/facebook/react-native/pull/6454
Differential Revision: D3049074
Pulled By: sahrens
fb-gh-sync-id: 61d085bb5c7bedf80204cdfb94e5c23542e15333
shipit-source-id: 61d085bb5c7bedf80204cdfb94e5c23542e15333
Summary:This makes the `refreshing` prop more 'controlled'. Before forgetting to set the refreshing prop in the onRefresh callback would make the js and native `refreshing` prop get out of sync and make the RefreshControl stop refreshing properly (see #5839).
I also added a simple usage example and a note about the refreshing prop in the doc.
There was also a small bug in the doc generation code that made the array of color show as [[object Object]] instead of [color] so I fixed that too.
** Test plan**
Tested using the UIExplorer example on iOS and Android. Not setting the `refreshing` prop to true in the `onRefresh` function should cause the RefreshControl to stop refreshing immediately and continue working properly after.
Closes#5839
Closes https://github.com/facebook/react-native/pull/6434
Differential Revision: D3046279
Pulled By: nicklockwood
fb-gh-sync-id: ebda04c659a10f0b9d468473c8d5c659256ca1b5
shipit-source-id: ebda04c659a10f0b9d468473c8d5c659256ca1b5
Summary:Add note about side-specific properties not being applied to `TextInput`s if `multiline=false`.
Fix formatting of docs describing other `multiline={true/false}` quirks.
Closes https://github.com/facebook/react-native/pull/2240
Differential Revision: D3037154
Pulled By: andreicoman11
fb-gh-sync-id: d64db906c2ab0054f2357b8e218725414d9868d6
shipit-source-id: d64db906c2ab0054f2357b8e218725414d9868d6
Summary: The exportedConstants method incurrs a penalty at bridge startup time for every module that implements it. This diff removes exportedConstants from a few modules that don't really need to use it.
Reviewed By: majak
Differential Revision: D2982341
fb-gh-sync-id: be016187d7b731a073311daacfcf88a0402e1688
shipit-source-id: be016187d7b731a073311daacfcf88a0402e1688
Summary:Follow-up to https://github.com/facebook/react-native/pull/5084
This…
- changes all requires within RN to `require('fbjs/lib/…')`
- updates `.flowconfig`
- updates `packager/blacklist.js`
- adapts tests
- removes things from `Libraries/vendor/{core,emitter}` that are also in fbjs
- removes knowledge of `fbjs` from the packager
Closes https://github.com/facebook/react-native/pull/5084
Reviewed By: bestander
Differential Revision: D2926835
fb-gh-sync-id: 2095e22b2f38e032599d1f2601722b3560e8b6e9
shipit-source-id: 2095e22b2f38e032599d1f2601722b3560e8b6e9
Summary:Fix the warning generated when some ScrollResponder methods call the deprecated form of scrollResponderScrollTo.
Closes https://github.com/facebook/react-native/pull/6138
Differential Revision: D2976681
fb-gh-sync-id: 3f5195aeebbffeccadb4bbffc55d52d7f89a9b2d
shipit-source-id: 3f5195aeebbffeccadb4bbffc55d52d7f89a9b2d
Summary:I forgot to add a deprecation warning to PullToRefreshViewAndroid when I worked on RefreshControl. This adds one as well as remove it from the website and remove the UIExplorer example. Now that we have versioned doc I think it is fine to remove deprecated stuff from the website so it is easier for users to know what component they should use. Last thing, I enabled flow in RefreshControl and fixed the one warning.
Closes https://github.com/facebook/react-native/pull/6055
Differential Revision: D2959502
Pulled By: mkonicek
fb-gh-sync-id: 9b23f84ea35c770bfe2a83d0fd3ec7e439669c33
shipit-source-id: 9b23f84ea35c770bfe2a83d0fd3ec7e439669c33
Summary:According to the [docs](http://facebook.github.io/react-native/releases/0.20/docs/picker.html#onvaluechange), `Picker`'s `onValueChange` should be called with `itemValue` and `itemPosition` but currently only `itemValue` is passed. This PR fixes that.
The position is passed as the 2nd parameter to not introduce any breaking change, and also to respect the current documentation.
The documentation doesn't need to be changed as it will be correct with this PR, but maybe it needs to be updated until this is merged?
Closes https://github.com/facebook/react-native/pull/5874
Differential Revision: D2953936
Pulled By: nicklockwood
fb-gh-sync-id: b8c1283013d4c7ed315066d8750f601f76f6bbb2
shipit-source-id: b8c1283013d4c7ed315066d8750f601f76f6bbb2
Summary:PR for https://github.com/facebook/react-native/issues/5958. The viewport meta tags if present, are overridden from the page and it is rendered according to the screen size. An example has been added in the Web View section of UIExplorer demo app.
Closes https://github.com/facebook/react-native/pull/6013
Differential Revision: D2953940
Pulled By: nicklockwood
fb-gh-sync-id: 012769f3a2a3f7dc942b60de02a9d1b80a27236e
shipit-source-id: 012769f3a2a3f7dc942b60de02a9d1b80a27236e
Summary:`scrollResponderInputMeasureAndScrollToKeyboard` is the only non-deprecated method in `ScrollResponder.js` that doesn't use the [new `scrollTo` API](6941c4e027). The other method that uses the deprecated API (`scrollResponderScrollWithoutAnimationTo`) is also deprecated, so it has been left unaltered.
Closes https://github.com/facebook/react-native/pull/5990
Differential Revision: D2953916
Pulled By: nicklockwood
fb-gh-sync-id: d692c598e6b85d1050e58b87146d01b031653a49
shipit-source-id: d692c598e6b85d1050e58b87146d01b031653a49
Summary:public
Default javaScriptEnabled to true on Android WebView
Also remove an old (about 6 weeks old) warning about a back compat supported property
Reviewed By: nicklockwood
Differential Revision: D2939482
fb-gh-sync-id: 2d476c3365f657da27ea370a033b23154750c2ea
shipit-source-id: 2d476c3365f657da27ea370a033b23154750c2ea
Summary:New prop `hitSlop` allows extending the touch area of Touchable components. This makes it easier to touch small buttons without needing to change your styles.
It takes `top`, `bottom`, `left`, and `right` same as the `pressRetentionOffset` prop. When a touch is moved, `hitSlop` is combined with `pressRetentionOffset` to determine how far the touch can move off the button before deactivating the button.
On Android I had to add a new file `ids.xml` to generate a unique ID to use for the tag where I store the `hitSlop` state. The iOS side is more straightforward.
terribleben worked on the iOS and JS parts of this diff.
Fixes#110
Closes https://github.com/facebook/react-native/pull/5720
Differential Revision: D2941671
Pulled By: androidtrunkagent
fb-gh-sync-id: 07e3eb8b6a36eebf76968fdaac3c6ac335603194
shipit-source-id: 07e3eb8b6a36eebf76968fdaac3c6ac335603194