Summary:
We only want to call onTransitionEnd after the transition has fully completed, including scene cleanup.
This will help avoid race conditions when we start new navigation after a transition completes.
Reviewed By: fkgozali
Differential Revision: D3712235
fbshipit-source-id: 146f30a0caf3d2fe164285fbef12293b7b161c6e
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:
NavigationTransitioner prepares for transition within `componentWillReceiveProps`, using previously-saved state to determine how to properly handle new props. If a transition is to take place, the code saves new info in state, executes the transition, and cleans up scenes within `_onTransitionEnd`.
If the transition is a jump-to transition, or otherwise takes very little time, then it is possible for the setState call within `_onTransitionEnd` to use state which hasn't yet been set by the code within `componentWillReceiveProps`, resulting in a failed transition.
This fix ensures that the initial setState call is completed before executing the transition.
Closes https://github.com/facebook/react-native/pull/8709
Differential Revision: D3550872
fbshipit-source-id: 1364612048025f5f970b44cbfd0c31acc4a60f56
Summary:
Its a minor Bug fix for rendering Title in NavigationHeader
Closes https://github.com/facebook/react-native/pull/8437
Differential Revision: D3507319
Pulled By: ericvicenti
fbshipit-source-id: ff4aa36be3c4991be11aabecbaad952c015a60e2
Summary:
This follows up the PR https://github.com/facebook/react-native/pull/8306
= Changes
1. Provides the TransitionProps (current and previous) to the function
`configureTransition`.
2. Adds a new member `timing` to `NavigationTransitionSpec`.
= Why
1. Helps people to customize the animation between transitions
2. Helps people to migrate from the deprecated `applyAnimation` prop.
Reviewed By: ericvicenti
Differential Revision: D3470802
fbshipit-source-id: be49becccd53aed7bc57093da1c7dae20153febd
Summary:
Fix a bug in NavigationScenesReducer that prevents scenes from re-rendering.
This happens when jumping the index between routes.
The fix is to add an new property `isActive` to `NavigationScene` to indicate the current active scene.
Reviewed By: ericvicenti
Differential Revision: D3479736
fbshipit-source-id: a71419887acd94ad2fead71596ca46419a88efef
Summary: When layout is measure, transtion props should be updated.
Reviewed By: ericvicenti
Differential Revision: D3479967
fbshipit-source-id: 14bcd96b9691b7ee68689393b4fef51dbd04b69f
Summary: This makes it easy to build Pager.
Reviewed By: ericvicenti
Differential Revision: D3479979
fbshipit-source-id: 71c0536eb190e8ad64feea99e4bda5e2d28801d2
Summary: Previously we would not re-compute `this._transitionProps` after cleaning up stale scenes, so the render caused by setState still had the stale scenes in the props
Reviewed By: hedgerwang
Differential Revision: D3471011
fbshipit-source-id: fd08ef7a21355a229e877c85f06d6584eb44f38e
Summary: This shall make it convenient to handle transition changes.
Reviewed By: ericvicenti
Differential Revision: D3442291
fbshipit-source-id: aee0ffe18ada40ef133484b4a4999f282c66c181
Summary:
This defines the generic function prop `render(props: NavigationTransitionProps)`
to NavigationTransitioner, which enables developer to render scenes, header, overlay,
underlay...etc.
Differential Revision: D3431478
fbshipit-source-id: 93dbc7da23ad8c95565b01f7865d1e8dfd4401f7
Summary:
Remove prop `onNavigate` from these views.
- NavigationAnimatedView
- NavigationCardStack
- NavigationCard
Also, the `sceneProps` onject that is passed to the `renderScene` function
no longer contains `onNavigate`.
The contract that `onNavigate` expects has been vague. Different data flow
system may expect complete different params for such function
For instance,
* onNavigate({type: 'back'});
* onNavigate({type: 'BACK'});
* onNavigate('back'});
We have no intention to unify such generic API since it's more likely to be
constrained by the data flow frameworks such as redux or flux.
Also, passing the prop `onNavigate` all the way down to the component that
invokes the navigation action can be really tedious. We'd expect developer
to either pass such callback (onNavigate) via context or just set up some
kind of static actions that any component can call directly.
`onNavigate` was previously added as a part of (redux-like) reducers-friendly
feature but that's no longer the case.
This new prop `onNavigateBack` is used to explicitly handle the case when the back button or back gesture
is performed.
Reviewed By: ericvicenti
Differential Revision: D3410873
fbshipit-source-id: a703cf0debd474cff33d6610e858b9c4bb3ecbf5
Summary:
== API Breaking Change ==
- Add unit tests to ensure that NavigationStateUtils does the right thing.
- Remove the logics that lets NavigationStateUtils accept empty value as input
and return a new state.
- Remove the method `NavigationStateUtils.getParent`, `NavigationStateUtils.set`. These methods are rarely used and they can be replaced by other methods.
Reviewed By: ericvicenti
Differential Revision: D3374934
fbshipit-source-id: 0fdf538d014d7c5b4aa1f15a0ee8db9dc91e33cd
Summary:
For navigation actions at high level, reducers from NavigationReducers does not
know anything about the app-specific state thus people won't use these reducers.
Instead, people should build their own reducers.
There are a lot of good libraries available that help people to reducing things if that's
what they really need.
At the low level, for navigation state changes that don't involve app-specific state,
`NavigationStateUtils` should server that kind of need.
`NavigationReducers` serves little benefit cause it does not know the app state, it does
not know how to traverse the navigation states which can be a tree, a list or a map.
That said, we hold no interest in owning in the core navigation library.
Reviewed By: ericvicenti
Differential Revision: D3372910
fbshipit-source-id: 797382b46e7d64b7ad578b51dd37e2b941faa83d
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).
For more info, see the ["Pull Requests" section of our "Contributing" guidelines](https://github.com/facebook/react-native/blob/mas
Closes https://github.com/facebook/react-native/pull/7974
Differential Revision: D3401208
Pulled By: nicklockwood
fbshipit-source-id: 7c807339ba512e05f848036fb40840cf3fee8df6
Summary:
The recent and upcoming API refactoring works makes maintaining
the examples harder and harder.
This removes the old examples that use too much deprecated APIs such as
Reducers, Animated View.
The new examples will be forcus on using new API with all-in-one sample
codes and detailed documentation.
Reviewed By: ericvicenti
Differential Revision: D3354711
fbshipit-source-id: ac6360b1573989eb075d91cb9bf1ae8357dce7fa
Summary:
In UI explorer, the route is made of an object which look like this.
```
{key: 'AppList', filter: 'query string from the search box'}
```
When a new search query is enter, a new `filter` value is applied, and the key `AppList`
remains the same.
In NavigationScenesReducer, we should compare the routes with both their keys and references.
The current implementation only compares the keys, which unfortunately depends on the a weak
assumption that all routes immutable and keys are unique.
In UI Explore, the route key is always 'AppList', which makes sense since we use the key
to match the scene, and whenever a new search query is provides, a new route will be created.
Reviewed By: nicklockwood
Differential Revision: D3357023
fbshipit-source-id: a3c9e98092f5ce555e5dbb4cc806bab2e67d8014
Summary:
NavigationState is composed of many things such as `index`, `routes`.
The only way to effectively compare navigation states is to assume their immutability
and simply compare their references.
That said, `navigationState.key` does not really serves anything useful. The key does
not make a navigation state more unique or comparable.
This diff makes `navigationState.key` irrelevant thus we could make NavigationState
simpler.
Reviewed By: ericvicenti
Differential Revision: D3351915
fbshipit-source-id: 75d5fa432d2a693f999a91b11e3bff1fdd42e61d
Summary:
- Address the issues reported at 7db7f78dc7 (commitcomment-17575647)
- Fix the logic that reduces the scenes.
- Fix the logic that computes the active scene for `renderOverlay`.
Reviewed By: ericvicenti
Differential Revision: D3344716
fbshipit-source-id: 3fce517ff1de212f412a77936012695bd2dcfc3c
Summary:
[Experimental API breaking changes]
The notion of `parent` or `children` in navigaton is misleading. We have no intention to maintain or
build the nested or hierarchical navigation states. To be clear, rename `navigationState.children` to
`navigationState.route`.
Reviewed By: ericvicenti
Differential Revision: D3332115
fbshipit-source-id: c72ed08acaf030fb9c60abf22fb15cc0f44b3485
Summary:
[public / experimental API breaking change]
The data type of `scene.navigationState` is `NavigationRoute`. Rename `scene.navigationState` to
`scene.route` to avoid confusion such as treating `scene.navigationState` as the actual global navigation
state (type: NavigationState).
Reviewed By: ericvicenti
Differential Revision: D3331076
fbshipit-source-id: 3ed989cc8492d398cbeb1b12186459deb261d1fb
Summary:
This is the first step to clarify and simplify the type definations about navigation state.
For now, `NavigationParentState` is actually used as the real navigation state and `NavigationState` is used
as a route in navigation, which has been confusion among the APIs.
To be clear, our APIs has no intention and interest in dealing with nested or hierarchical navigation states,
and we should avoid have the name like `ParentState` or `children`.
To fully migrate the types, theer will be a lot of code changes and this is just the first step to rename.
= What's Next?
1. rename `navigationState.children` to `navigationState.routes` (breaking change!)
2. remove `navigationState.key` from its type defination.
Reviewed By: ericvicenti
Differential Revision: D3321403
fbshipit-source-id: 3e39b60f736c1135bc85d8bf2b89027d665e28d4
Summary:
- Fork NavigationAnimatedView to NavigationTransitioner
- NavigationAnimatedView will soon be deprecated and we'd ask people to use NavigationTransitioner instead.
Difference between NavigationTransitioner and NavigationAnimatedView
- prop `applyAnimation` is removed.
- new prop `configureTransition`, `onTransitionStart`, and `onTransitionEnd` are added.
tl;dr;
In NavigationAnimatedView, we `position` (an Animated.Value object) as a proxy of the
transtion which happens whenever the index of navigation state changes.
Because `position` does not change unless navigation index changes, it won't
be possible to build animations for actions that changes the navigation state
without changing the index.
Also, we believe that the name `Transitioner` is a better name for this core component
that focuses on transitioning. Note that the actual animation work is done via
`<Animated.View />` returnd from the `renderScene` prop.
Reviewed By: ericvicenti
Differential Revision: D3302688
fbshipit-source-id: 720c3a4d3ccf97eb05b038baa44c9e780aad120b
Summary:
... used as both a shape and plain object.
this splits them out so both parts can be used as needed.
NavigationPropTypes.SceneRenderer is a PropTypes shape
NavigationPropTypes.SceneRendererProps is the plain object that makes up the shape.
Closes https://github.com/facebook/react-native/pull/7518
Differential Revision: D3317322
Pulled By: ericvicenti
fbshipit-source-id: e8a31e05130e6647b63f68dbef31bc874550948c
Summary:
= Breaking Change (for experimental features) =
Major API changes in NavigationAnimatedView
= New prop `transition` for scene renderer
In NavigationAnimatedView, we should not use `position` as a proxy of the
transtion which happens whenever navigation state changes.
Because `position` does not change unless navigation index changes, it won't
be possible to build animations for actions that replace navigation state
without changing the index.
This diff introduces an abstract prop `transition` that is exposed to the scene
renderers.
= Replace `applyAnimation` with `configureTransition`.
Expose a new optional prop `configureTransition` that allows people to configure
transitions easily.
For instance, to configure the transition, do this:
```
function configureTransition() {
return {
dutation: 123,
easing: Easing.easeInOut,
};
}
```
<NavigationAnimatedView configureTransition={configureTransition) />
```
Reviewed By: ericvicenti
Differential Revision: D3278698
fbshipit-source-id: b790b92e0fabb42488ff1135b1c37a3f0e9420f7
Summary:
= Breaking Change (for experimental features) =
Major API changes in NavigationAnimatedView
= New prop `transition` for scene renderer
In NavigationAnimatedView, we should not use `position` as a proxy of the
transtion which happens whenever navigation state changes.
Because `position` does not change unless navigation index changes, it won't
be possible to build animations for actions that replace navigation state
without changing the index.
This diff introduces an abstract prop `transition` that is exposed to the scene
renderers.
= Replace `applyAnimation` with `configureTransition`.
Expose a new optional prop `configureTransition` that allows people to configure
transitions easily.
For instance, to configure the transition, do this:
```
function configureTransition() {
return {
dutation: 123,
easing: Easing.easeInOut,
};
}
```
<NavigationAnimatedView configureTransition={configureTransition) />
```
Reviewed By: ericvicenti
Differential Revision: D3278698
fbshipit-source-id: 25ebad286d8b41f46c35c0f32d6023ebd01f19e7
Summary:
= Breaking Change (for experimental features) =
<NavigationView /> serves no obvious benefit and it's costly to maintain it.
- its features could be completely replaced by NavigationAnimatedView without
enabling the transtion animation.
- it could also be replaced with a simple view and normal scene renderer.
Reviewed By: ericvicenti
Differential Revision: D3280547
fbshipit-source-id: 4ac3dbe92ceb9107a1f6e77a78bd6021485e78a9
Summary:
The containers in NavigationExperimental are not appropraite because the state should be held by the app's architecture, be it redux, flux, or simple component state.
This diff moves the examples over to simple component state, but there are several other examples of how to use NavigationAnimatedView and the navigation reducers with redux:
- https://github.com/jlyman/RN-NavigationExperimental-Redux-Example
- Switching the f8 app with redux to navigation experimental: https://github.com/fbsamples/f8app/pull/14
Reviewed By: hedgerwang
Differential Revision: D3219911
fb-gh-sync-id: eb0b323e2c165c32027fbd00dc6197ad441d6552
fbshipit-source-id: eb0b323e2c165c32027fbd00dc6197ad441d6552
Summary:
This should simplify the renderScene usage a bit because the react key is required and this will make sure they are rendered with the right key automatically.
It changes the string to make sure people do not rely on this API for anything else.
Reviewed By: javache
Differential Revision: D3033933
fb-gh-sync-id: 036424af28693be32c3a3290f5c6667a6a6a04ac
fbshipit-source-id: 036424af28693be32c3a3290f5c6667a6a6a04ac
Summary:
NavigationLegacyNavigator was originally created to help people to migrate to the new
navigation library without API changes. Therefore we'd have to port all the old APIs that
don't necessarily seem align well with the new navigation library.
Consider the production usage of NavigationLegacyNavigator does not exist, it's better
to kill it and we'd just rename the `Navigator` to `NavigatorDeprecated` later instead.
Reviewed By: ericvicenti
Differential Revision: D3263704
fb-gh-sync-id: a851fda1516d694cb7d119f5a1344f8fc676f7fd
fbshipit-source-id: a851fda1516d694cb7d119f5a1344f8fc676f7fd
Summary:The initial layout used to render scenes does not contain the actual
width and height measured and causes the issue as described at
https://github.com/ericvicenti/navigation-rfc/issues/61
The fix is to update the layout and re-render scenes once layout
is modified. Also scenes renderer should also consider the case that
when the layout is not measured yet.
Reviewed By: ericvicenti
Differential Revision: D3162143
fb-gh-sync-id: 197574329d3849cad2a21e07e1bd5e800f74c3ea
fbshipit-source-id: 197574329d3849cad2a21e07e1bd5e800f74c3ea
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:Current docs show an Appetize.io example for AlertIOS doc. This pull request adds that feature across all applicable iOS and Android docs. So if a doc has an example in UIExplorer, it shows up in the top right and clicking to Play should navigate to the relevant example.
The changes here also touched NavigationExperimental to fix a typo that prevented iOS deep link from working. Code was also added to help support Android deep links but there's an outstanding issue (a race condition) around how Android deep links trigger getInitialURL in NavigationRootContainer that prevents this from fully working.
For adding the docs, a few things were done outside this pull request:
1/ Release builds for UIExplorer Android and iOS apps were uploaded to Appetize.io. The Appetize.io info (public key to run the build) is embedded in the docs.
2/ The iOS build was generated by making a few changes to get a local bundle. The current UIExplorer set up doesn't support "react-native run-ios".
Regarding the Appetize bu
Closes https://github.com/facebook/react-native/pull/6306
Differential Revision: D3129651
Pulled By: bestander
fb-gh-sync-id: d296d64db8236faa36f35484bb6b362990caf934
fbshipit-source-id: d296d64db8236faa36f35484bb6b362990caf934
Summary:This address the issue reported at
https://github.com/facebook/react-native/issues/6579#issuecomment-200984628
NavigationView should have the same API as NavigationAnimatedView does except
that NavigationView does not need the APIs for animation.
This unify the API of our core components so that people can freely
compose views with both NavigationAnimatedView or NavigationView.
Reviewed By: fkgozali
Differential Revision: D3096076
fb-gh-sync-id: 7536777a7d637da62a2636d750f9d91c5a0eb45f
fbshipit-source-id: 7536777a7d637da62a2636d750f9d91c5a0eb45f
Summary: This will make the code more readable.
Reviewed By: ericvicenti
Differential Revision: D3096663
fb-gh-sync-id: 540d2107ea3cd4c60aabdf7a6503c8c22bc4a985
fbshipit-source-id: 540d2107ea3cd4c60aabdf7a6503c8c22bc4a985
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: 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: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