Summary:
**motivation**
Right now `SwipeableQuickActions` only allows two actions. Let this limit be in the userland.
cc fred2028
Closes https://github.com/facebook/react-native/pull/8528
Differential Revision: D4211729
Pulled By: ericvicenti
fbshipit-source-id: 903592190b9855ffe9da44864cdc276bc1e18a7c
Summary:
If a SwipeableRow does not have background color defined, QuickAction is rendered below the row. In such case, you can leverage openRowID defined in dataSource. For instance, one can render quickAction only for the open row. The openRowID, however, does not clear when the row is closed. It only clears when the ListView is scrolled. This is s small PR to fix address it.
Closes https://github.com/facebook/react-native/pull/11380
Differential Revision: D4500952
Pulled By: mkonicek
fbshipit-source-id: a965dfb45b77cc1669de405b627d13e2cee59420
Summary:
Without allowing Native Responder on Android, ListView get's Deadlocked while trying to scroll. This happens as soon as a PanResponder fires.
This Commit prevents this Issue and the iOS Optimization for Locking / Unlocking Listview Scrolls does a good job on Android too. So there's no need to prevent the Native Responder.
**Test plan (required)**
Compile on Android in Production Mode and try to scroll before and after this change.
Closes https://github.com/facebook/react-native/pull/8556
Differential Revision: D4438057
Pulled By: hramos
fbshipit-source-id: 05f3b7e6b4e49f5c941c7e1ce72c8bf6d66a9a28
Summary:
Currently, swipeableList expects maxSwipeoutDistance to be a number. This breaks when you want each row to have a variable width slideoutView.
This PR add support for passing maxSwipeoutDistance as a number(as before) or a function which gets the current rowData for conditionally returning the distance based on the row data.
Closes https://github.com/facebook/react-native/pull/10189
Differential Revision: D4168561
Pulled By: hramos
fbshipit-source-id: b78564f83279cab3bf04297034ca78edfff74be7
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.**
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).
For more info, see
Closes https://github.com/facebook/react-native/pull/10413
Differential Revision: D4028108
fbshipit-source-id: 99a864dfda578d640f582b296583591415ba26cd
Summary: If a user scrolls the `SwipeableListView`, any open row(s) will close.
Reviewed By: furdei
Differential Revision: D3903787
fbshipit-source-id: efd9ae896ba50ad6e83e72d52bc1f5c0c35efd61
Summary: Cleans things up and also defers rendering rows if there is an interaction happening.
Reviewed By: achen1
Differential Revision: D3817231
fbshipit-source-id: fd08d0ca7cb6c203178f27bfc5a0f55469135c3a
Summary: Modified logic and constants to make the swipable row animations feel more natural and smooth.
Reviewed By: fred2028
Differential Revision: D3801391
fbshipit-source-id: d4301fe01a190803b5bc27373a9755086b6c431d
Summary:
Due to an earlier commit, we now have to use the full path for requiring `performanceNow`.
**Test plan (required)**
Verified that the IncrementalExample works when adding it to UIExplorer.
Closes https://github.com/facebook/react-native/pull/9595
Differential Revision: D3775101
Pulled By: javache
fbshipit-source-id: 6252ce8c872896f4cfdb9a31bdbc79d6aaf4684d
Summary: create new RCTI18nManager.js to warp-up native module I18nManager and fix current use of it.
Reviewed By: ericvicenti
Differential Revision: D3547427
fbshipit-source-id: 53a695c94ca6bba2f566d0725c553e58d60bf451
Summary:
**motivation**
Currently when using a non-touchable visible row for a SwipeableRow, the scroll on list view is blocked.
**Test Plan**
```
<SwipeableListView
dataSource={dataSource}
renderRow={() => <View style={styles.row}/>}
renderQuickActions={() => <View style={styles.hiddenrow}/>}
/>
```
* Tested that when using non-touchable for renderRow allows scrolling on list view.
* Tested that when using touchable for renderRow allows scrolling on list view.
cc fred2028
Closes https://github.com/facebook/react-native/pull/8537
Differential Revision: D3542407
Pulled By: fred2028
fbshipit-source-id: b7ad7ff7c7dd1b717544746a85bb265414aa18f4
Summary:
Flipped the gesture for SwipeableRow
Provide RTL support for SwipeableRow. When developer set RTL layout in their app, all the animation and gesture will change to RTL status.
Reviewed By: fkgozali
Differential Revision: D3532919
fbshipit-source-id: 76fc94cdaa8457350e9bbe3366aa714c9eb45245
Summary:
This is simple fix to SwipeableListView. According to SwipeableListViewDataSource, the only method available is cloneWithRowsAndSections. If you try to get the data from a SwipeableListView, without this fix it won't work. This change fixes the problem so that SwipeableListView can work correctly.
Closes https://github.com/facebook/react-native/pull/8493
Differential Revision: D3523384
fbshipit-source-id: 359ff274fabcab676ed6dee24f0652c4146cde69
Summary: I noticed sometimes the swipeable row prioritizes the list view's vertical scroll too much, or returns to closed position if swiped a little distance but at high velocity. These new thresholds help both cases.
Reviewed By: hedgerwang
Differential Revision: D3441994
fbshipit-source-id: 84a9fdf63a33b3047a9a0205e87d8c489e9a6631
Summary: Slower bounce during mount and right swipe, so it feels less jarring to users.
Reviewed By: hedgerwang
Differential Revision: D3420169
fbshipit-source-id: d5da87c4a64eecf478edd626c96f5541ab94b56e
Summary: So users can know how to use
Reviewed By: hedgerwang
Differential Revision: D3399028
fbshipit-source-id: 5ce97c5464f1975145aba1bcf4b79550394859ae
Summary: Allow some right swipe so users know swiping is a possibility, with some bounceback.
Reviewed By: fkgozali
Differential Revision: D3388836
fbshipit-source-id: 596a6be3c641ff0ee6ac32d7c0d798478edef72b
Summary:
Makes compute call async from willReceiveProps and fixes crashes with proper bounds in render
function instead. This means that fast prop updates won't force rapid and synchronous row increments during
initial render.
Check `rowData` and `rowKey` explicitly so clients don't have to worry about preserving === rowData containers
around Relay data to prevent re-renders.
Also moves layout jump warning behind DEBUG since it's not a common issue any more.
Reviewed By: devknoll
Differential Revision: D3357710
fbshipit-source-id: ee2e5be04261d5722abd07a063b345960b0c5cbe
Summary: - Removed some styling from `SwipeableRow` that wasn't doing much and made slide out view full height
Reviewed By: fkgozali
Differential Revision: D3322849
fbshipit-source-id: 811eee9032c142c61d303ae7e966d8ef7903adaf
Summary:
Before:
- Android had the slideout row flash upon render due to it being rendered first
- iOS had the left side of each row load first, then rerender to show entire row when `scrollViewWidth` is available
Reason:
- Android was loading the slideout view first without an opacity check
- iOS was loading the swipeable view with width 0 first then stretching to `scrollViewWidth` when it was available via `onLayout`
Fix:
Render swipeable view with `flex: 1` then render slideout view
Reviewed By: fkgozali
Differential Revision: D3321466
fbshipit-source-id: 92a3b5e22034e06d05986ddb8c348796bafbbf34
Summary:
- Replace some fixes that were accidentally lost in local rebase that prevent jumpiness when incremental is disabled.
- Require each row to have a key specified by the caller to prevent jumping because of accidental duplicates or unneeded/problematic row re-rendering because of legit re-ordering.
Reviewed By: steveluscher
Differential Revision: D3322006
fbshipit-source-id: 0019aab07cb1fe2b148a14b5818de53aa373eb50
Summary:
Incremental rendering is a tradeoff between throughput and responsiveness because it yields. When we have plenty of
buffer (say 50% of the target), we render incrementally to keep the app responsive. If we are dangerously low on buffer
(say below 25%) we always disable incremental to try to catch up as fast as possible. In between, we only disable
incremental while actively scrolling since it's unlikely the user will try to press a button while scrolling.
This also optimizes some things then incremental is switching back and forth.
I played around with making the render window itself adaptive, but it seems pretty futile to predict - once the user
decides to scroll quickly in some direction, it's pretty much too late and increasing the render window size won't help
because we're already limited by the render throughput at that point.
Reviewed By: ericvicenti
Differential Revision: D3250916
fbshipit-source-id: 930d418522a3bf3e20083e60f6eb6f891497a2b8
Summary: Default image icon size for Quick Actions could cause slideout view to bleed over the slideable view. All styling has been removed and must now be passed in, thus allowing every caller to control size for best fit.
Reviewed By: furdei
Differential Revision: D3315696
fbshipit-source-id: 8f8b3d2cf7a005d42a18d434d9e0080c64597be0
