Summary:**Issue:**
In the Navigator if a user attempts to navigate backwards (or forwards) through the route stack by swiping and they perform the gesture too quickly, the gesture is lost and nothing happens.
**Cause:**
In the `_matchGestureAction` function, the variable `moveStartedInRegion` is created and evaluates the gesture to determine if it was initiated in a valid region, (a.k.a. within the `edgeHitWidth`). The issue arises because `moveStartedInRegion` uses `currentLoc` (which is created from `gestureState.moveX`/`Y`) and when the gesture is performed using a flick of the finger, the first value of the `currentLoc` is outside of the `edgeHitWidth`.
**Solution:**
The solution is to track the coordinates of the initial grant (`gestureState.x0`/`y0`), and use that value instead of the `currentLoc` when evaluating `moveStartedInRegion`. The `currentLoc` is still needed however, for when the gestureState does not have a an initial x and y value, because the pan responder has not been granted.
Closes https://github.com/facebook/react-native/pull/6249
Differential Revision: D3168726
Pulled By: ericvicenti
fb-gh-sync-id: f2ac462e59bdc38536b99cac6a4877c99fa4e869
fbshipit-source-id: f2ac462e59bdc38536b99cac6a4877c99fa4e869
Summary:I basically want to build a transparent NavigationHeader, so I need to be able to set the pointerEvents of the NavigationHeader.
Closes https://github.com/facebook/react-native/pull/6881
Differential Revision: D3168620
Pulled By: ericvicenti
fb-gh-sync-id: 679f3f5858142f468be329771ea281c31e1f0d40
fbshipit-source-id: 679f3f5858142f468be329771ea281c31e1f0d40
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:First I searched for special cases that destructor PropTypes:
```
(?s)React\s*=\s*require\('react\-native'\).*(Children|PropTypes)[^\{\}]*\}\s*=\s*React;
```
I split them up manually.
Then I replaced the React = require('react-native') + destructuring pattern...
```
(?s)(const|var)\s+React\s*=\s*require\('react\-native'\)(.*[^\{\}]*\}\s*=\s*)React;
```
...with...
```
$1 React = require('react');
$1 ReactNative = require('react-native')$2ReactNative;
```
I used lint to figure out if I left some unnecessary imports.
Finally I grepped for just
```
React\s*=\s*require\('react\-native'\)
```
to catch any remaining patterns.
Also, `} = React.NativeModules` -> `} = ReactNative.NativeModules`.
Reviewed By: spicyj
Differential Revision: D3158991
fb-gh-sync-id: f97e8e921e193d6ea1a49d8d1bf3f09be7bed5c3
fbshipit-source-id: f97e8e921e193d6ea1a49d8d1bf3f09be7bed5c3
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:When navigating from one view to another you can still interact with
the current view. This means that a user can tap a button multiple times and trigger multiple transitions.
The view that is being transitioned off the screen should not be allowed to
receive any user interaction while it is being transitioned.
Reviewed By: javache
Differential Revision: D3143202
fb-gh-sync-id: cc033bbdf0cb9e717f62d2fcf751155406da846c
fbshipit-source-id: cc033bbdf0cb9e717f62d2fcf751155406da846c
Summary:There was an issue where the title component could overlap the left component and it would block the left component from receiving touches.
I only stumbled across this because we have a default title component which stretches most of the width and it was covering the edge of the left component. I think left/right components are more likely to be actionable than the title component so they should take priority in the touch order (ie. be rendered last).
Closes https://github.com/facebook/react-native/pull/6618
Differential Revision: D3144191
fb-gh-sync-id: 9ccd31714b2401d02eaaf4b5b24ed6afb60041c7
fbshipit-source-id: 9ccd31714b2401d02eaaf4b5b24ed6afb60041c7
Summary: The iOS native card stack only responds if the gesture starts on the left 30 px on the screen.
Reviewed By: hedgerwang
Differential Revision: D3137201
fb-gh-sync-id: 40e28d5696870b98731e92d6e42d00638b9bb15f
fbshipit-source-id: 40e28d5696870b98731e92d6e42d00638b9bb15f
Summary:Currently, if the Navigator with the default `NavigatorNavigationBar` has two scenes on its `routeStack` and the bottom one defines a `RightButton` but the top one doesn't, a touch to the location of the underlying `RightButton` will trigger its action.
This fix checks if the button's opacity is set to 0 (indicating it has been transitioned off the scene and shouldn't be interacted with) and ignores touch events if so.
Closes https://github.com/facebook/react-native/pull/5624
Differential Revision: D3139553
fb-gh-sync-id: 6d6da1459e289499b6d8769120a3b6114548c090
fbshipit-source-id: 6d6da1459e289499b6d8769120a3b6114548c090
Summary:At the beginning of the navigator docs it says " See Navigator.SceneConfigs for default animations and more info on scene config options."
but then this is the only information available:
<img width="658" alt="screen shot 2016-03-23 at 2 40 49 am" src="https://cloud.githubusercontent.com/assets/1247834/13977670/733cdaa6-f0a1-11e5-92e6-fc98725f65e0.png">
And the only way of knowing about the available options is to look at the source code. I think a lot of people will appreciate this...
If you think this is too much, maybe adding a link to the source code would help.
Closes https://github.com/facebook/react-native/pull/6599
Differential Revision: D3088592
fb-gh-sync-id: f11025b76441e9394ce42ed6c796fa1ace3e8c27
fbshipit-source-id: f11025b76441e9394ce42ed6c796fa1ace3e8c27
Summary: This will make the code more readable.
Reviewed By: ericvicenti
Differential Revision: D3096663
fb-gh-sync-id: 540d2107ea3cd4c60aabdf7a6503c8c22bc4a985
fbshipit-source-id: 540d2107ea3cd4c60aabdf7a6503c8c22bc4a985
Summary:The doc of props "navigationBar" in Navigator is not detailed enough. I make an improvement to it.
Closes https://github.com/facebook/react-native/pull/6615
Differential Revision: D3102065
fb-gh-sync-id: da96e3c422e053d0a8203bbd160ea10ed590878a
fbshipit-source-id: da96e3c422e053d0a8203bbd160ea10ed590878a
Summary:- All the public sub component renderers should implement the interface
NavigationSceneRenderer, which will help to reuse renderer or
replace renders for different composition.
- Perf improvement. <NavigationHeader /> is rendering way more
sub component than necessary, we shall fix that.
- No UI or behavior change.
Reviewed By: ericvicenti
Differential Revision: D3091442
fb-gh-sync-id: fba5f7ce74597fa6036b5b216c02b06052801983
shipit-source-id: fba5f7ce74597fa6036b5b216c02b06052801983
Summary:Currently there?s an inconsistency between the animations used in `NavigationAnimatedView` (`spring`) and those in `NavigationCardStack` (`timing`), which is noticeable when switching between the two implementations.
By removing the `_applyAnimation` method, the `NavigationAnimatedView` will simply use its [default `applyAnimation`](6c22a2174e/Libraries/NavigationExperimental/NavigationAnimatedView.js (L56-L67)), making the animation styles the same.
**Before** (with `Animated.timing`)
Video: http://quick.as/Yexku8DdJ
**After** (with the default `NavigationAnimatedView` animations)
Video: http://quick.as/qrqbsnj8n
Closes https://github.com/facebook/react-native/pull/6636
Differential Revision: D3094638
Pulled By: ericvicenti
fb-gh-sync-id: 6e1c7c54b4ef102c4003719381d334d2c6f7a531
shipit-source-id: 6e1c7c54b4ef102c4003719381d334d2c6f7a531
Summary: We need to support animation and gesture for Pager.
Reviewed By: ericvicenti
Differential Revision: D3066596
fb-gh-sync-id: 1c1a3d34b4298b4b0dd158f817057ae22dea72f4
shipit-source-id: 1c1a3d34b4298b4b0dd158f817057ae22dea72f4
Summary:Add ability to specify custom left, right components, and title component. Style the `NavigationBar` according to the Platform.
Refer https://github.com/ericvicenti/navigation-rfc/pull/21
cc ericvicenti
Closes https://github.com/facebook/react-native/pull/5971
Differential Revision: D3080601
Pulled By: ericvicenti
fb-gh-sync-id: 7b921cd36b4c2ec1edf6f52629f1f9890d272dfd
shipit-source-id: 7b921cd36b4c2ec1edf6f52629f1f9890d272dfd
Summary:Hi,
I am using https://github.com/aksonov/react-native-router-flux / https://github.com/exponentjs/ex-navigator and I needed a way to update my redux store with the current route.
I'm using the navigation context to do this:
```javascript
if (navigationContext) {
const handler = () => {
updateCurrentRouteState(navigationContext.currentRoute);
};
navigationContext.addListener('willfocus', handler);
navigationContext.addListener('didfocus', handler);
}
```
However, when the whole stack is replaced, no event is emitted. This PR aims to fix that.
Closes https://github.com/facebook/react-native/pull/5596
Differential Revision: D3080004
Pulled By: ericvicenti
fb-gh-sync-id: 0ef4ecebec7076275b6433c80aae6102cf28c039
shipit-source-id: 0ef4ecebec7076275b6433c80aae6102cf28c039
Summary: Port the legendary props `onWillFocus` and `onDidFocus` from `Navigator` to `NavigationLegacyNavigatorRouteStack`.
Reviewed By: fkgozali
Differential Revision: D3063530
fb-gh-sync-id: 89583b8c80ee6ed0ef844a56b942a2d74b98717f
shipit-source-id: 89583b8c80ee6ed0ef844a56b942a2d74b98717f
Summary:- Move the logics that manage the routes stack into `NavigationLegacyNavigatorRouteStack`
- Add more unit tests for NavigationLegacyNavigatorRouteStack.
- Keep NavigationLegacyNavigator as a pure view as possible as we could.
Reviewed By: fkgozali
Differential Revision: D3060459
fb-gh-sync-id: 2c6802115c3f6ca5e396903f0d314ff54129524c
shipit-source-id: 2c6802115c3f6ca5e396903f0d314ff54129524c
Summary:Per offline discussion with ericvicenti, we'd like to reudce the complexity by
keeping <NavigationCard /> nothing more than just a simple `<Animated.View />`,
which helps us to avoid over generalize the styles, gestures of what the Navigation card
needs to be.
The proposalis to use the same props (NavigationSceneRendererProps) that is used to render
the scene to generate the style and pan handlers needed for the navigation card.
No behavior changes, just implementation details clean up work.
Reviewed By: ericvicenti
Differential Revision: D3037225
fb-gh-sync-id: f6e718a282d25a319f5d8efd3e2ffebc66b2c8cb
shipit-source-id: f6e718a282d25a319f5d8efd3e2ffebc66b2c8cb
Summary:Given that you can do all kinds of animations other than `Animated.timing`, it made no sense to have `setTiming`. In addition, you can't intuitively tell that this is the callback where you would do custom animations.
The discussion took place on Discord with ericvicenti: https://discordapp.com/channels/102860784329052160/154015578669973504
Closes https://github.com/facebook/react-native/pull/6235
Differential Revision: D2999121
Pulled By: hedgerwang
fb-gh-sync-id: f587b865de11ba5e8dc9c430720252ffb5d12794
shipit-source-id: f587b865de11ba5e8dc9c430720252ffb5d12794
Summary:This is the initial implementation of the Navigator done with the NavigationExperimental library.
There will be following diffs to support more features that are currently available from the Navigator.
Reviewed By: ericvicenti
Differential Revision: D3016084
fb-gh-sync-id: ed509fc86e9dc67b5334be9e60b582494fd52844
shipit-source-id: ed509fc86e9dc67b5334be9e60b582494fd52844
Summary: I think we should dispose events in FIFO order
Reviewed By: fkgozali
Differential Revision: D2987425
fb-gh-sync-id: a4ad256512725d0bed0086b642e10fe7e7715070
shipit-source-id: a4ad256512725d0bed0086b642e10fe7e7715070
Summary: This fixes a couple of breakages introduced by the switch to fbjs
Reviewed By: bestander
Differential Revision: D3000078
fb-gh-sync-id: 2971d049030f754d5001f6729716373a64078ddf
shipit-source-id: 2971d049030f754d5001f6729716373a64078ddf
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: Add card stack item that moves from the right or the bottom.
Reviewed By: ericvicenti
Differential Revision: D2975659
fb-gh-sync-id: a04724943375ba0a9931eafb2aa82d6d8c31acfe
shipit-source-id: a04724943375ba0a9931eafb2aa82d6d8c31acfe
Summary:Fix an issue when using ListView and define `renderSeparator` but the implementation returns null.
In such cases the sectionHeaderIndices mismatch the child element index and the app shows a warning like "Sticky header index 18 was outside the range {0, 13}".
Closes https://github.com/facebook/react-native/pull/5800
Differential Revision: D2980005
Pulled By: vjeux
fb-gh-sync-id: cd2d51d83698ed189bb65ea40b7b073644136b49
shipit-source-id: cd2d51d83698ed189bb65ea40b7b073644136b49
Summary:We'd plan to build the `NavigationLegacyNavigator` that is meant to replace
Navigator seemlessly without API changes. While the APIs remain
compatible with Navigator, it should be built with the new
Navigation API such as `NavigationAnimatedView`...etc.
To ensure that the new NavigationLegacyNavigagtor delivers the same
UX and maintains APIs compability, we'd start with using the exact same
examples as the same ones that Navigator uses.
Reviewed By: ericvicenti
Differential Revision: D2955273
fb-gh-sync-id: b4723cf54ea2258e5589f39dceeaee88be2b93f0
shipit-source-id: b4723cf54ea2258e5589f39dceeaee88be2b93f0
Summary:Basic implementation of the component NavigationCardStack that animates
a list of NavigationCard.
This will be used to port the UX of teh current Navigator.
Reviewed By: ericvicenti, fkgozali
Differential Revision: D2967065
fb-gh-sync-id: a72920e141364fab328e45a083aef21ca5e6fe0c
shipit-source-id: a72920e141364fab328e45a083aef21ca5e6fe0c
Summary: Revise APIs of reducers, and ensure the stack reducer can support sub-reducers
Reviewed By: javache
Differential Revision: D2959915
fb-gh-sync-id: 20b28b9ead7ace3373489a806486999048d32aef
shipit-source-id: 20b28b9ead7ace3373489a806486999048d32aef
Summary: There is a NavigationState type within this module so the name cannot be shared
Reviewed By: hedgerwang
Differential Revision: D2938311
fb-gh-sync-id: c5208755c9dfa5bf0e67666957c01e203ddd4218
shipit-source-id: c5208755c9dfa5bf0e67666957c01e203ddd4218
Summary:
public
I was looking into the missing panels at the bottom of the <ListView> - Grid Layout example, and found that it was caused by several problems, some in the example and some in ListView itself.
The first problem seemed to be a bug in the `_getDistanceFromEnd()` method, which calculates whether the ListView needs to load more content based on the distance of the visible content from the bottom of the scrollview. This was previously using the function
Math.max(scrollProperties.contentLength, scrollProperties.visibleLength) - scrollProperties.visibleLength - scrollProperties.offset
to calculate the amount the user could scroll before they run out of content. This sort-of works in most cases because `scrollProperties.contentLength` is usually longer than `scrollProperties.visibleLength`, so this would generally evaluate to
scrollProperties.contentLength - scrollProperties.visibleLength - scrollProperties.offset
which meant that it would be positive as long as there was content still to be displayed offscreen, and negative when you reached the end of the content. This logic breaks down if `contentLength` is less than `visibleLength`, however. For example, if you have 300pts of content loaded, and your scrollView is 500pts tall, and your scroll position is zero, this evaluates to
Math.max(300, 500) - 500 - 0 = 0
In other words, the algorithm is saying that you have zero pts of scroll content remaining before you need to reload. But actually, the bottom 200pts of the screen are empty, so you're really 200pts in debt, and need to load extra rows to fill that space. The correct algorithm is simply to get rid of the `Math.max` and just use
scrollProperties.contentLength - scrollProperties.visibleLength - scrollProperties.offset
I originally thought that this was the cause of the gap, but it isn't, because ListView has `DEFAULT_SCROLL_RENDER_AHEAD = 1000`, which means that it tries to load at least 1000pts more content than is currently visible, to avoid gaps. This masked the bug, so in practice it wasn't causing an issue.
The next problem I found was that there is an implict assumption in ListView that the first page of content you load is sufficient to cover the screen, or rather, that the first _ second page is sufficient. The constants `DEFAULT_INITIAL_ROWS = 10` and `DEFAULT_PAGE_SIZE = 1`, mean that when the ListView first loads, the following happens:
1. It loads 10 rows of content.
2. It checks if `_getDistanceFromEnd() < DEFAULT_SCROLL_RENDER_AHEAD` (1000).
3. If it is, it loads another `DEFAULT_PAGE_SIZE` rows of content, then stops.
In the case of the ListView Grid Layout example, this meant that it first loaded 10 cells, then loaded another 1, for a total of 11. The problem was that going from 10 to 11 cells isn't sufficient to fill the visible scroll area, and it doesn't change the `contentSize` (since the cells wrap onto the same line), and since ListView doesn't try to load any more until the `contentSize` or `scrollOffset ` changes, it stops loading new rows at that point.
I tried fixing this by calling `_renderMoreRowsIfNeeded()` after `_pageInNewRows()` so that it will continue to fetch new rows until the `_getDistanceFromEnd()` is less than the threshold, rather than stopping after the first page and waiting until the `contentSize` or `scrollOffset` change, but although this solves the problem for the Grid Layout example, it leads to over-fetching in the more common case of a standard row-based ListView.
In the end, I just increased the `pageSize` to 3 for the Grid Layout example, which makes more sense anyway since loading a page that is not a multiple of the number of cells per row confuses the `_renderMoreRowsIfNeeded` algorithm, and leads to gaps at the bottom of the view.
This solved the problem, however there was still a "pop-in" effect, where the additional rows were paged in after the ListView appeared. This was simply a misconfiguration in the example itself: The default of 10 rows was insufficient to fill the screen, so I changed the `initialListSize` prop to `20`.
Reviewed By: javache
Differential Revision: D2911690
fb-gh-sync-id: 8d6bd78843335fb091e7e24f7c2e6a416b0321d3
shipit-source-id: 8d6bd78843335fb091e7e24f7c2e6a416b0321d3
Summary:
public
- Intro new back action
- Add support in the two main reducers
- Use it in examples to support Android back button
- Disable NavigationCard gestures on Android
Reviewed By: hedgerwang
Differential Revision: D2914154
fb-gh-sync-id: d4dce6538e19613a2ffca21e2e3b2ecaded3d5dc
shipit-source-id: d4dce6538e19613a2ffca21e2e3b2ecaded3d5dc