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
Summary:
Not much to add. My OCD spotted this 😄
Closes https://github.com/facebook/react-native/pull/10275
Differential Revision: D3984542
Pulled By: hramos
fbshipit-source-id: 2de8c8f7f5c2c518e0ec5277087095e0553c72d6
Summary:
These are caused by new [syntax checking](1285131e3e/CHANGELOG.md (v6113-2016-10-01)) introduced by babylon.
"The single rest at the end only applies to binding `let { x, ...y } = obj;` and assignment `({ x, ...y } = obj).`"
I'd say this really should be cherry picked into the stable branch.
**Test plan**
1. install babylon@6.11.3
2. see that things break
3. apply patch
4. things work
5. make sure all instances were fixed (I used `\.\.\..*,.*\n.*=` in IntelliJ regex format—find all ... followed by newline followed by =)
Issue #10199
Closes https://github.com/facebook/react-native/pull/10200
Differential Revision: D3974066
Pulled By: javache
fbshipit-source-id: 3f3c1e9df01a3b3bdd61dd3863416c638d3ed98d
Summary:
The Navigator component inconsistently emits the `willfocus` event.
While it is emitted in `Navigator#resetTo`, `Navigator#push`, `Navigator#pop` and event `Navigator#replaceAtIndex` it is not emitted from `Navigator#immediatelyResetRouteStack`. This leads to surprising inconsistencies when working with these events.
With the PR I suggest to emit the `willfocus` event before resetting the route stack.
Closes https://github.com/facebook/react-native/pull/10125
Differential Revision: D3931284
fbshipit-source-id: 6e4f45c6d38426bcd0acc8f8c39478524032a03a
Summary:
_renderScene would unnecessary test if `this.state.transitionFromIndex != null` twice.
The left side and right side of the 'or' statement would always be the same.
For cleaner code I suggest to remove it.
Closes https://github.com/facebook/react-native/pull/10042
Differential Revision: D3923058
fbshipit-source-id: 7466c1f0f24eac3f9f296debd9a5e9f5320aea28
Summary:
In certain cases, if a navigation title is present in place of an empty nav stack, the first breadcrumb may steal part of the title's touch events since it's hardcoded to sit 1/4 from the left of the screen (for animation reasons). This diff fixes it, allowing titles on an empty nav stack to be entirely touchable while retaining all other breadcrumb functionality.
Also, applied some suggested lint changes.
Reviewed By: hedgerwang
Differential Revision: D3891909
fbshipit-source-id: 97d1fb3bba4e4118401d84cec2d8836b94bfde75
Summary:
`Navigator` throws an error if using a custom `NavigationBar` component that does not have a `immediatelyRefresh` method present.
Closes https://github.com/facebook/react-native/pull/9438
Differential Revision: D3838928
Pulled By: mkonicek
fbshipit-source-id: 74d62ef09e179f457a4b14f8537dfaf0d4697322
Summary:
During development of an app I decided upon NavigationExperimental as I found it easily configurable with my Redux stores and make it work the way I wanted. One thing I found missing was the ability to decide if gestures were on or not for the card stack. In my case I need the gestures off as they conflict with what I am trying to do. This PR simply opens up the ability to turn the gestures for a CardStack off.
Testing was completed via UI Explorer. An additional example replicating the existing one with the new setting set to false was created. To ensure nothing broke I tested both the original example and new example to ensure gestures worked (and didn't work) when expected.
I did not see any unit tests around NavigationExperimental but if I simply missed them I would be more then happy to update/add any.
Closes https://github.com/facebook/react-native/pull/9505
Differential Revision: D3749880
Pulled By: ericvicenti
fbshipit-source-id: dfa42ff8b6c8b41490ad1efc931b364e47058243
Summary: Provide RTL support in NavigationCardStack
Reviewed By: fkgozali
Differential Revision: D3740172
fbshipit-source-id: 69466d24e148d0d81cb9f21c55f545abda46ac35
Summary:
`<Text>` accepts more than just string as its children; and it's handy to be able to style nav titles without a proptype warning throwing
Closes https://github.com/facebook/react-native/pull/8338
Differential Revision: D3719045
fbshipit-source-id: a02d181b5e133dbe467fbaca794f0d2119be2da7
Summary:
The `shouldComponentUpdate` policies were meant to be a built-in optimization, but it prevents rendering at unexpected times, which has been causing confusion. Apps can use normal react optimization techniques to avoid extra rendering- Navigation will no longer attempt to optimize the render tree
Addresses https://github.com/facebook/react-native/issues/7720
Reviewed By: hedgerwang
Differential Revision: D3649735
fbshipit-source-id: 9461620445a6a57a1635113df7ec4026c0d6b9d2
Summary:
Not a API change, but this may break the layout of exisitng apps that
uses NavigationHeader.
For now, NavigationHeader uses absolute position, which makes it hard for
NavigationCardStack to determine the height of the scenes.
Theoretically, the height of the scenes would be the height of the cards
stack minus the height of the header.
That said, if we want to support the headers with different height (e.g.
MyIOSHeader or MyAndroidHeader), we're forced to expose the height of the
headers and manually compute the height of the scenes.
Alternatively, if the header does not use absolute position, the height
of the scenes can adjust automatically with flex box, and that's what this
commit is about to do.
Reviewed By: ericvicenti
Differential Revision: D3671119
fbshipit-source-id: 26e48f801da3661c5d7dce4752ba927621172f4a
Summary:
Currently, the NavigationExperimental `Header` only renders correctly on iOS when the system status bar is visible. There are legitimate reasons to hide the status bar, especially when displaying in landscape.
This PR adds a `statusBarHeight` prop to the header, which defaults to 20 on iOS and 0 (no status bar) on Android. Changing this value causes the extra space at the top of the header reserved for the status bar to change.
I've tested this change in my own app on iOS with `statusBarHeight` set to 0, 20, and `undefined`, and ensured that it works correctly.
Closes https://github.com/facebook/react-native/pull/8983
Differential Revision: D3668637
fbshipit-source-id: 777a0c53e8fd1caa35ce4980ca3118adcf83b62d
Summary:
NavigationCardStack is a custom component, and its API should be explicit, not
too generic..
In NavigationCardStack, the prop `renderOverlay` is actually used to render
the NavigationHeader, and we uses absolute position to build the layout for
the header and the body.
One of the problem with using absolute postion and fixed height to build the
layout that contains the header is that the header can't have variant height
easily.
Ideally, if the layout for the header used flex-box, we'd ve able to be more
adaptive to deal with the header that has variant height.
That said, let's rename `renderOverlay` to `renderHeader`, then build the
proper layout that explicitly works better with the header.
If we to need to support overlay in navigation, we may consider add
`renderOverlay` later, if it's really necessary.
Reviewed By: ericvicenti
Differential Revision: D3670224
fbshipit-source-id: ff04acfe9dc995cb57117b3fd9b07d5f97b9c6ee
Summary:
Hi folks !
🔧 Fix the navigation card stack pan responder when the `vertical` direction is enabled.
**Issue:**
When using a `ScrollView` with the `vertical` direction enabled, the pan handler catch the gesture before the `ScrollView`.
I don't know why there was no default value here for `RESPOND_POSITION_MAX_VERTICAL` 5162eb3254
ericvicenti could you tell me what you think about setting a default value for `RESPOND_POSITION_MAX_VERTICAL` ? 😃
Thanks !!
**EDIT June 15, 2016**
I'll update this PR this week end to provide a way to give custom values as there is no magic value for `RESPOND_POSITION_MAX_VERTICAL`
**EDIT June 24, 2016**
I've added a props `gestureResponseDistance` to control both the `RESPOND_POSITION_MAX_VERTICAL` and `RESPOND_POSITION_MAX_HORIZONTAL`
Closes https://github.com/facebook/react-native/pull/8076
Differential Revision: D3605973
Pulled By: ericvicenti
fbshipit-source-id: 158d88cf8ebbab742bf0b38c217ae502e9dd1963
Summary: Provide RTL support in NavigationPager
Reviewed By: fkgozali
Differential Revision: D3536850
fbshipit-source-id: 29890a125dc5e001b4c10208cd53bfeca0d9b5c3
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:
Decreased the distance threshold so that the user doesn't need to swipe a large distance to
set the pan responder.
Also, set a threshold for the velocity so that a simple flick can be detected.
Reviewed By: hedgerwang
Differential Revision: D3540354
fbshipit-source-id: 251a4f14dc014bc32b3a83fa8de419f86ca40b84
Summary:
For RTL experiment, we need to swap all the Left and Right gesture and animation.
Provide RTL support for Navigator in RN.
Reviewed By: hedgerwang
Differential Revision: D3519811
fbshipit-source-id: b53d9bf901ec056614658b627823d2225bdc82b1
Summary:
With facebook/react-native@c57bac4, `NavigationTransitioner` passes the currently active `scene` in transition `props`. This simplifies the handling of transition changes when rendering overlay.
🍺
Closes https://github.com/facebook/react-native/pull/8298
Differential Revision: D3533447
Pulled By: ericvicenti
fbshipit-source-id: df568dc5cf5d57d8948b9f0400a8d693cf5564e1