Summary: Before that it was not possible to get a ref to a navigation bar (unless using Navigator's internal `_navBar` prop)
Closes https://github.com/facebook/react-native/pull/3755
Reviewed By: svcscm
Differential Revision: D2674315
Pulled By: nicklockwood
fb-gh-sync-id: 26120f7bcbb675e8217b8bd963dcc6ed314d4ba3
Summary: public
The gesture that moves scene around should only be attached when the
move starts at the moment that the first move is granted.
No move would ever be granted if the move event is prevented by the
decendent children (e.g. a slider component).
For now, the move gesture is attached at `onPanResponderGrant`
instead of `onPanResponderMove` thus we'd create "ghost-move-gesture"
when no actual moves is received my the navigator.
Reviewed By: fkgozali
Differential Revision: D2683802
fb-gh-sync-id: 50ae877787167511df48378304bd2ad665c73300
Summary: This issue shows up if you have a really long left nav item. When the navigator is pushed in iOS, the long nav item will be visible alongside the new nav item.
Steps to repro:
1/ Modify Examples/UIExplorer/Navigator/NavigationBarSample.js
2/ In NavigationBarRouteMapper.LeftButton, make the following change
<Text style={[styles.navBarText, styles.navBarButtonText]}>
Very Long Title {previousRoute.title}
</Text>
3/ On iOS, get the UIExplorer project up and navigate to Navigator > Navbar Example > Next (top-right nav item) > Next
You should see the overlap.
<img width="592" alt="leftnavitem_issue" src="https://cloud.githubusercontent.com/assets/691109/11086934/b5b82e26-880a-11e5-9945-13901346a5c5.png">
With these changes the overlap is gone.
Closes https://github.com/facebook/react-native/pull/4067
Reviewed By: svcscm
Differential Revision: D2641934
Pulled By: ericvicenti
fb-gh-sync-id: 962536b97f77a3b7f176423aa11dc94f24f07332
Summary: public
We've noticed that some of the navigator functions are called after the navigator
being unmounted. This diff adds the checks to protect the navigator from throwing
error when it's calling function after be unmounted.
Reviewed By: fkgozali
Differential Revision: D2629484
fb-gh-sync-id: 1cbee02b1a8d2a5d285e7d76f382d2599ed8caed
Summary: 1. Add a new api `top` which returns the root navigator of a nested navigator.
2. Remove the param `context` from the method `addListener` because it's not used and not necessary.
public
Reviewed By: fkgozali
Differential Revision: D2613852
fb-gh-sync-id: 0d5544422ff0be7875824989a4fbefbef9aac986
Summary: public
Navigator subscribes to its internal animation spring that may still
asks navigator to re-render after being unmounted.
This diff clears the listeners of its animation spring once navigator
is unmounted.
Reviewed By: zjj010104
Differential Revision: D2588434
fb-gh-sync-id: 2b3ee65d3a6c3d45e5c6904d1dc65ac5a3e4534a
Summary: public
In Navigator, there are several places that mutate `this.state.presentedIndex`
with the express `this.state.presentedIndex = destIndex` instead of calling
`this.setState`, which creates the problem that not all internal states are
updated within the same React update cycle.
One of the symptoms is that over-swiping within the Navigator may throw JS error
due to `this.state.sceneConfigStack` and `this.state.presentedIndex` are not both
updated.
The workaround is to bypass the over-swiping gesture to avoid JS error.
Reviewed By: ericvicenti
Differential Revision: D2557140
fb-gh-sync-id: 1e5c9047ed17c04a63e2a568118848b00723fb1d
Summary: Adds the API that enables the navigation events capturing and bubbling which is the feature
that is enabled if the nested navigation contexts is created by the navigator.
This would allow developer to observe or reconcile navigation events within the navigation tree.
public
./Libraries/FBReactKit/jest
Reviewed By: zjj010104
Differential Revision: D2546451
fb-gh-sync-id: dfc9d16defaa563b9e80fd751a20570f6e524b74
Summary: This allows for the iOS-style navigation bar on Android and vice versa in order to simplify design. It is entirely optional in that NavigationBars will continue to defauly to their platform-specific style, but you can override it with the `navigationStyles` prop:
```js
<Navigator.NavigationBar
navigationStyles={Navigator.NavigationBar.StylesIOS}
/>
```
Fixes#2995.
Closes https://github.com/facebook/react-native/pull/3028
Reviewed By: @svcscm
Differential Revision: D2527902
Pulled By: @ericvicenti
fb-gh-sync-id: c7b1bfac200b5e03fc0d9dfb8acc8b916c825595
Summary: @public
Add method `stopPropagation` and `stop` to NavigationEvent so we can stop event easily once event bubbling and capturing is supported.
Reviewed By: @fkgozali
Differential Revision: D2471903
Summary: The component will crash if the prop is not provided. This helps with a better
error message in the console output.
Closes https://github.com/facebook/react-native/pull/2894
Reviewed By: @svcscm
Differential Revision: D2461752
Pulled By: @ericvicenti
Summary: When the touch gets terminated, it is not guaranteed that there is an active gesture. It looks like this was causing crashes
@public
Reviewed By: @chaceliang
Differential Revision: D2441469
Summary:
When mutation of a stack happens, we'd like to compute the diff of the stacks (before and after) so that
we can know which routes are removed in the new stack.
This diff adds a new method `substract` which does what we need.
Summary:
Disabling the scene this way would make the scene height go to zero and mess up the scroll position. By setting the bottom to the same distance, the view does not get resized and the scroll position is preserved through a scene disable cycle.
Summary:
# Summary
Add a method `keyOf` to NavigationRouteStack.
The method `keyOf` returns a key that is associated with the route.
The a route is added to a stack, the stack creats an unique key for it and
will keep the key for the route until the route is rmeoved from the stack.
The stack also passes the keys to its derived stack (the new stack created by the
mutation API such as `push`, `pop`...etc).
The key for the route persists until the initial stack and its derived stack no longer
contains this route.
# Why Do We Need This?
Navigator has needs to use an unique key to manage the scenes rendered.
The problem is that `route` itself isn't a very reliable thing to be used as the key.
Consider this example:
```
// `scene_1` animates into the viewport.
navigator.push('scene_1');
setTimeout(() => {
// `scene_1` animates off the viewport.
navigator.pop();
}, 100);
setTimeout(() => {
// Should we bring in a new scene or bring back the one that was previously popped?
navigator.push('scene_1');
}, 200);
```
Because we currently use `route` itself as a key for the scene, we'd have to block a route
until its scene is completely off the components tree even the route itself is no longer
in the stack otherwise we'd see strange animation of jumping scenes.
# What's Next
We're hoping that we can build pure reactive view for NavigationRouteStack easily.
The naive implementation of NavigationRouteStackView may look like this:
```
class NavigationRouteStackView {
constructor() {
this.state = {
staleScenes: {},
};
}
componentWillReceiveProps(nextProps) {
if (nextProps.stack !== this.props.stack) {
var stale;
var staleScenes = {...this.state.staleScenes};
this.props.stack.forEach((route, index, key) => {
if (nextProps.stack.keyOf(route) !== key) {
stale = true;
staleScenes[key] = {route, index, key, stale};
}
});
if (stale) {
this.setState({
staleScenes,
});
}
}
}
render() {
var scenes = [];
this.props.stack.forEach((route, index, key) => {
scenes.push({route, index, key});
});
Object.keys(this.state.staleScenes).forEach(key => {
scenes.push(this.state.staleScenes[key]);
});
scenes.sort(stableSortByIndex);
return <View>{scenes.map(renderScene)}</View>;
}
}
```
Summary:
If user taps the back button quickly, the app crashes becuase "pop"
internally only checks `this.state.presentedIndex` which does not
always update when transtion happens.
This diff addresses this issue.
Summary:
Hides disabled scenes using `top` instead of `left`, which fixes a bug with the native UITabBar. When the UITabBar's width is zeroed because the scene has `left: SCREEN_WIDTH, right: 0` applied, this triggers a bug with the kerning of the tab titles. Instead, zeroing the height by setting `top: SCREEN_HEIGHT` avoids the bug.
Also applies `pointerEvents="none"` to disabled scenes so that views in the off-screen scenes definitely don't receive touches, which was occurring before.
Fixes#1401, fixes#2011
Closes https://github.com/facebook/react-native/pull/2104
Github Author: James Ide <ide@jameside.com>
Summary:
Re-landing D2229686 after fixing bugs mentioned in D2250586
onItemRef is old and no longer needed now that the parent renders the scenes. This removes it from Navigator and all of our clients.
This is a breaking change to users of Navigator, but it is easy to transition to a ref in renderScene instead
Summary:
While adeveloper requests the emitter to emit an event, the emitter
may not emit the event immediately instead of putting the request
into a queue and process it later.
This diff allows the developer to provide a callback which will be called
when the event has been emitted.
For instance:
```
class NavigationContext {
push(nextRoute) {
var nextStack = this._stack.push(nextRoute);
this.emit(
'change',
{
reason: 'push',
nextStack: nextStack,
nextRoute: nextRoute,
},
this._onPush
);
}
_onPush(event){
if (event.defaultPrevented) {
return;
}
this._stack = event.nextStack;
this.emit('change');
}
}
```
Summary:
idStack is going away soon. This removes all references to it. Looking at the internal state of navigator will make you have a bad time.
The biggest change is switching to the new component-freezing techinique in the navigation bars. This way we avoid dependence on the idStack to provide a scalar ID for each route.
Summary:
onItemRef is old and no longer needed now that the parent renders the scenes. This removes it from Navigator and all of our clients.
This is a breaking change to users of Navigator, but it is easy to transition to a ref in renderScene instead
Summary:
Introducing the data structure NavigationRouteStack that focused on managing
navigation routes stack.
The goal is to make <Navigatior /> thinner by moving stack management logic into
its own class and make sure it's well-tested.
Teh next step will be cleaning up <Navigatior /> and add `NavigationRouteStack` to
`NavigationContext`.
Summary:
A minor improvement suggestion: `Navigator.getCurrentRoutes()` probably shouldn't return its `routeStack` backing array as-is, because the caller may mutate it, causing the internal state of the navigator to go out of sync. Instead a shallow copy of the routes should be returned.
I stumbled on this problem in my app by attempting to read the navigator state as follows:
```
let routes = Navigator.getCurrentRoutes();
let current = routes.pop();
let previous = routes.pop();
```
Which led to an exception at next navigation event.
CLA signed.
Closes https://github.com/facebook/react-native/pull/1888
Github Author: Jani Evakallio <jani.evakallio@gmail.com>
Summary:
This makes sure to call willFocus before new scenes get mounted. This fixes cases where the keyboard is dismissed on willfocus events which incorrectly happens *after* the autofocus in a new scene. The keyboard was opening and getting immediately closed
@public
Test Plan: Test keyboard autofocus in new nav scenes on iOS
Summary:
Updating range is too complicated. We can keep cached versions of the previously rendered scenes in a map.
@public
Test Plan: Verify that the active scene is the only thing that get re-rendered, and that rendering doesn't happen during transitions or gestures. Test navigation thouroughly in AdsManager
Satyajit Sahoo
Wenjing Wang
Gabe Levi
Huang Yu
Danny Arnold
Hedger Wang
Christine Abernathy
James Ide
Elia Grady
Jan Kassens
Tamara Woodson
Eric Vicenti
Yamill Vallecillo
Emily Janzer
Martin Konicek
Matheus Santos
Kevin Gozali
Jani Evakallio
Alex Kotliarskyi
