Summary: It's ok for them to be empty, so we should check!
Reviewed By: yungsters
Differential Revision: D4664411
fbshipit-source-id: c66e98458708eee59757fa665b3a05972f1c1b70
Summary:
Wrapping them in ScrollViewStickyHeader broken the onLayout and would always give y = 0
because it is now relative to the wrapper.
This uses some not-so-great react magic, but fixes the bugs with no aparent side-effects.
Note we also need to kill the StaticRenderer wrapper that ListView introduces. I think this was
probably a premature optimization anyway since there are usually not many headers and they are
usually pretty cheap to render. If people care, they can use `shouldComponentUpdate` with the
rendered components.
Reviewed By: yungsters
Differential Revision: D4654622
fbshipit-source-id: 1ea557ef64327d1f4df53b22fedd678da1549288
Summary: I think these are sufficiently baked. Also beef up comments.
Reviewed By: yungsters
Differential Revision: D4632604
fbshipit-source-id: 64ae6b240a05d62e418099f7403e1781f9b4717c
Summary:
We really need a better list view - so here it is!
Main changes from existing `ListView`:
* Items are "virtualized" to limit memory - that is, items outside of the render window are unmounted and their memory is reclaimed. This means that instance state is not preserved when items scroll out of the render window.
* No `DataSource` - just a simple `data` prop of shape `Array<any>`. By default, they are expected to be of the shape `{key: string}` but a custom `rowExtractor` function can be provided for different shapes, e.g. graphql data where you want to map `id` to `key`. Note the underlying `VirtualizedList` is much more flexible.
* Fancy `scrollTo` functionality: `scrollToEnd`, `scrollToIndex`, and `scrollToItem` in addition to the normal `scrollToOffset`.
* Built-in pull to refresh support - set set the `onRefresh` and `refreshing` props.
* Rendering additional rows is usually done with low priority, after any interactions/animations complete, unless we're about to run out of rendered content. This should help apps feel more responsive.
* Component props replace render functions, e.g. `ItemComponent: ReactClass<{item: Item, index: number}>` replaces `renderRow: (...) => React.Element<*>`
* Supports dynamic items automatically by using `onLayout`, or `getItemLayout` can be provided for a perf boost and smoother `scrollToIndex` and scroll bar behavior.
* Visibility callback replaced with more powerful viewability callback and works in vertical and horizontal mode on at least Android and iOS, but probably other platforms as well. Extra power comes from the `viewablePercentThreshold` that lets the client decide when an item should be considered viewable.
Demo:
https://www.facebook.com/groups/576288835853049/permalink/753923058089625/
Reviewed By: yungsters
Differential Revision: D4412469
fbshipit-source-id: e2d891490bf76fe14df49294ecddf78a58adcf23
Summary:
Explain the **motivation** for making this change. What existing problem does the pull request solve?
I had tried fixing a broken link in a previous commit (#11453). My commit was merged, but it did not resolve the underlying problem. I have looked into how links should be formed for the docs and have fixed the original problem as well as updated all other links to be consistent.
Previous link formats:
- /docs/sample.html <-- broken link
- sample.html <-- broken link
- https://facebook.github.io/react-native/docs/sample.html <-- works
- /react-native/docs/sample.html <-- works
- docs/sample.html <-- works (permalink format)
This PR updates all links to the permalink format.
**Test plan (required)**
I ran the website locally and manually tested half of the links in each category. They all worked.
```
$ cd website
$ npm install && npm start
```
Closes https://github.com/facebook/react-native/pull/12064
Differential Revision: D4489153
Pulled By: mkonicek
fbshipit-source-id: bf0231d941ba147317595c3b3466dc579a887169
Summary: There's scenarios where you might want to retain transparency behind the header, but have a solid background for the scene stack and its transitions.
Reviewed By: ericvicenti, dwwoelfel
Differential Revision: D4471681
fbshipit-source-id: 529e999b96b02a00e8d625169989dda49fb3ddaa
Summary:
When something comes in from the right, we swipe from left to
right to move back. That means, when something comes in from the bottom,
we should swipe from top to bottom to get rid of it. This diff makes that
behavior occur - right now it's somewhat nonsensical as both jumpBack
and jumpForward are mapped to the same gesture.
thanks to #11192 for making gestures work on VerticalUpSwipeJumps
Reviewed By: ericvicenti, shergin
Differential Revision: D4412129
fbshipit-source-id: 6a3b202b0a90ca459b4ef106ba5bf48d0b1aec9e
Summary:
Hi,
The (as of yet unreleased) commit 5537055bf8 added some ListView and ScrollView mocks, but they leave out the original properties passed into them, which broke some of my tests (e.g. by excluding some properties like `testID`, for example, from the render tree) and I assume might break others' as well.
This PR makes it so the ListView mock directly returns the scroll component (instead of wrapping it in a View), and has ListViewMock and ScrollViewMock pass their given properties through.
Closes https://github.com/facebook/react-native/pull/11847
Differential Revision: D4408497
Pulled By: sahrens
fbshipit-source-id: 7ec01c35d6b8efeb97761cddffdb4075d09c7d70
Summary:
Hello,
This PR adds a property to the `ListView` to enable and disable to sticky sections headers behaviour. Current this is enabled by default and there is no way to disable it. It has been previously discussed in #1974 where there was a suggestion to add the `ListView` inside `ScrollView`. This is bad for performance, but some people were using that as a workaround. satya164 suggested someone submitting a PR, which is why I'm here 😉
I have tested the property manually by adding `stickySectionHeaders={false}` to the `<ListView> Paging` example in `UIExplorer`. I have also tested that the current behaviour still stands, so this is a non-breaking change.
I have also checked that the website displays the new documentation.
I couldn't see anywhere to add automated tests to this, but if there is feel free to point it out and I'll update this PR.
I tried running `npm run lint` to check the code style, but it spat out loads and loads of errors. I presume I have something set up incorrectly. Feel
Closes https://github.com/facebook/react-native/pull/11700
Differential Revision: D4380916
fbshipit-source-id: 7782043afc9f0108c81f97952fed60b153479cac
Summary:
I see there is a string matching inconsistency in `Libraries/CustomComponents/Navigator/Navigator.js` and `Libraries/CustomComponents/Navigator/NavigatorSceneConfigs.js`, which caused a bug resulting in gestures not working for vertical SceneConfigs. This PR fixes the inconsistency, and the bug.
**Motivation for making this change**
When working with the navigator, I was using the `VerticalUpSwipeJump` Navigator SceneConfig. The gesture to pop to the previous scene (in this case `jumpBack`) was not working.
**How I tested?**
I changed these strings (as shown in this PR) and swiped down. After these changes, everything worked as expected.
**Example**
In `Libraries/CustomComponents/Navigator/Navigator.js`, we check for gesture direction strings `bottom-to-top` and `top-to-bottom` in multiple places, but nowhere do we ever check for `up-to-down` and `down-to-up`.
```
var isTravelVertical = gesture.direction === 'top-to-bottom' || gesture.direction === 'bottom-to-top';
var isTravelInverted =
Closes https://github.com/facebook/react-native/pull/11192
Differential Revision: D4392103
Pulled By: ericvicenti
fbshipit-source-id: fd80578031f94b1b409815481c82e481c7ff2f13
Summary:
Transition animations are not very customizable right now with NavigationExperimental, unless I am missing something big. This PR allows NavigationCardStack to receive the `horizontalCardStyleInterpolator` and `verticalCardStyleInterpolator` props to override the default interpolators.
See the gif, transition animation changes from the default one (with scale) to a custom one (without scale) when passing in a custom interpolator. (The custom interpolator is an exact copy of the one in `NavigationCardStackStyleInterpolator.forHorizontal`, minus the scale transform.)
Let me know if there's a robust way to test, but I couldn't find anything.
**To address**
The new `canUseNativeDriver` function on NavigationCardStackStyleInterpolator, which returns `true`, is dependent on the interpolator, so custom interpolators may need to falsify this. Didn't include it on the first pass since I wasn
Closes https://github.com/facebook/react-native/pull/11082
Differential Revision: D4362540
Pulled By: ericvicenti
fbshipit-source-id: 2ebd0047c147ac3d6c43ce880661c99de8fd0880
Summary:
`Fake` components are simplified so snapshots are stable and reliable, and references are exported
so that interactions like `onRefresh` and `onScroll` can be called manually. Currently there is just
one global export for each class, but we may change this in the future if we need to manage multiple
`Fake`s of the same type in one render tree.
Right now these must be installed explicitly, but I might move them into `__mocks__` folders if it
seems reasonable to make them defaults.
Reviewed By: cpojer
Differential Revision: D4318207
fbshipit-source-id: 62802353a98b09ca1c80804ef7201ea63091f94a
Summary:
Gestures now work with native animations so we can enable it, it is also not needed anymore to check if the native module exists since we print a warning in the Animated module now.
**Test plan**
Tested that animations and gesture work properly in the UIExplorer example. Also been using native animations with NavigationExperimental (ex-nav) in an app for a while.
Closes https://github.com/facebook/react-native/pull/11234
Differential Revision: D4321763
Pulled By: ericvicenti
fbshipit-source-id: 255bed5bfed3b93bdc10939b5a03d4d8b00ceade
Summary:
The typecheck inside of NavigationCard is PropTypes.any while in NavigationCardStack it is View.propTypes.style.
let's make them consistent to avoid unnecessary warnings. (e.g. trying to pass a animationStyle as cardStyle)
Closes https://github.com/facebook/react-native/pull/9808
Differential Revision: D4277323
Pulled By: ericvicenti
fbshipit-source-id: c30b4a21675cad98c19f5c6522e286d776bfa20d
Summary:
> Explain the **motivation** for making this change. What existing problem does the pull request solve?
Just fixed a typo.
Feel free to make the change directly in the repo without my credit if the process is easier than accepting this PR.
Closes https://github.com/facebook/react-native/pull/11164
Differential Revision: D4236963
Pulled By: mkonicek
fbshipit-source-id: 72c059596216602f9ab30dea6eb5f9cdbf89d31b
Summary:
Sometimes, `gesture.overswipe` can be `null`/`undefined` in `_moveAttachedGesture` resulting in a crash. This change adds a null check to avoid the crash. `_matchGestureAction` has a similar check so it looks like this case was overlooked in `_moveAttachedGesture`.
**Test plan (required)**
My team's app is using this change.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/11017
Differential Revision: D4207277
Pulled By: ericvicenti
fbshipit-source-id: a22817c2ebec1c996583269a59d6767f5713771b
Summary:
Cards which are not visible because another card is occluding them are still being rendered by Android resulting in overdraw. This results in wasted GPU time because some pixels are drawn multiple times. This change reduces overdraw by changing the opacity of occluded cards to 0.
This bug was found using the tools described in Android's overdraw docs: https://developer.android.com/topic/performance/rendering/overdraw.html
**Test plan (required)**
This change is being used in my team's app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/10908
Differential Revision: D4175758
Pulled By: ericvicenti
fbshipit-source-id: 4bfac7df16d2a7ea67db977659237a9aa6598f87
Summary:
:( this confused me, I thought I was missing some configuration or something. But the UIExplorer app has sticky headers on iOS, and non-sticky headers on Android, so I guess that's that.
Closes https://github.com/facebook/react-native/pull/10335
Differential Revision: D4039482
Pulled By: hramos
fbshipit-source-id: 34be2db4b15dec2f28a808a9bbc2eb00b0e35525
Summary:
`NavigationCardStackPanResponder` uses `__getValue` and the `stopAnimation` callback value which both doesn't work with native driven animation. The workaround here is to add a value listener so the JS value of the AnimatedValue gets updated too so `__getValue` has a relatively up to date value. This value should be good unless JS lags behind native a lot but that should not happen during a navigation gesture. Also added a comment that explains the hack.
**Test plan**
Tested in an app that uses native driven animations with a back gesture. This also needs #10643 and #10641 for everything to work properly.
Closes https://github.com/facebook/react-native/pull/10642
Differential Revision: D4135496
Pulled By: ericvicenti
fbshipit-source-id: 395aff78b16a37ad9407207a05504fdd6311f733
Summary:
Since native and non-native animations do not work together check if the animated value is native and set useNativeDriver accordingly. So untill we move to always using the native driver this is needed. This and another fix in NativeAnimations module will allow using native animations to transitions with gestures.
**Test plan**
Tested in an app that uses native driven animations with a back gesture. This also needs #10643 and #10642 for everything to work properly.
Closes https://github.com/facebook/react-native/pull/10641
Differential Revision: D4135972
Pulled By: ericvicenti
fbshipit-source-id: 8e65574ebb296da044f4d03bf1eedee4a37ebdac
Summary:
The `position` animated value is used for scale, translateX, and tranlateY
animations, which are all supported by NativeAnimatedHelper. Unfortunately,
native animations are incompatible with JS driven animations, which the
`enableGestures` flag enables.
This diff therefore conditionally enables native animations based on the native
module's precense, and the state of `enableGestures`.
Ideally the animations would be refactored so that they could fully leverage
native animations, as they are far superior for navigational components.
Reviewed By: oyvindkinsey
Differential Revision: D4020977
fbshipit-source-id: 8e1d015c4d41fee103469f6f9ffa02ff4f1f5517
Summary:
This brings RN Navigator to add HorizontalSwipeJumpFromLeft animation.
HorizontalSwipeJumpFromRight has been implemented but FromLeft version of SwipeJumpAnimation hasn't been there.
Closes https://github.com/facebook/react-native/pull/10406
Differential Revision: D4035212
fbshipit-source-id: edcbae18148e533b02a7d056de03154fb86280d0
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:
In the `Additional Scenes` section, the `TouchableHighlight` component is used, but is not present in the import statement.
This is confusing and results in a `Can't find variable: TouchableHighlight` error.
This PR attempts to correct this confusion.
Closes https://github.com/facebook/react-native/pull/10276
Differential Revision: D3997058
Pulled By: hramos
fbshipit-source-id: 22ebf39cd39d8a76427c89cecc774ff9aef2c3c8
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/10299
Differential Revision: D3997827
Pulled By: ericvicenti
fbshipit-source-id: a98e112d95015842936a9d2bdc89553772ba49c2
Eric Vicenti
Spencer Ahrens
David Adams
Matt Mahoney
Tim Yung
Dan Scanlon
Paul Mestemaker
Martin Konicek
Sean Kinsey
Hedger Wang
Kevin Lee
Dan Hassin
Matt Oakes
alekhurst
Pieter De Baets
Neo
Janic Duplessis
gl8997@gmail.com
Seph Soliman
Adam Comella
Jared Forsyth
Naisheel Verdhan
d.chernyatiev
YUYA FUJIMOTO
leeight
Konstantin Raev
Jan Kassens
Jeff Thomas
