* Refactor, move child navigation to navigation prop
This fixes our descriptor caching issue, and unblocks explicit nested navigation options.
As a side effect, the following APIs are introduced:
- navigation.getChildNavigation(routeKey) , which is useful for explicitly getting children config info
- navigation.router, access to the static router
- router.childRouters[routeName] , an optional way to access the children routers directly. If childRouters are not provided in a router, we will fall back on getComponentForRouteName(routeName).router, which is the previous external API for this (although it may be slower because it will require the whole screen component).
* supporting tests and top level actions
* cleanup
* Transitioner: Fix instantaneous transitions
The transitioner will always perform an animation on state change. Instead we should check if the navigation state is requesting a transition with isTransitioning. If not, we follow a similar codepath to transitioning, without any animation.
* Update .eslintrc
* Export getNavigationActionCreators
`react-navigation-redux-helpers` generally needs to duplicate whatever `createNavigationCreator` does. As of `react-navigation@2.0`, that includes using `getNavigationActionCreators` to construct the top-level `NavigationScreenProp`.
This PR isn't strictly needed, as it's possible to import from the file directly. But that's a brittle approach, and not particularly discoverable for anybody attempting to use a "non-stateful" navigator with their state management library of choice.
* Further refinements after writing the new helper
* Final refinement of NavigationScreenProp's relationship with _DefaultActionCreators
* Resolve merge conflicts
Using two new utils:
1. `createNavigationPropConstructor`, which is now preferred over `createReduxBoundAddListener`.
2. `initializeListeners`, which is necessary to trigger the event listeners with the initial state.
* [flow] Remove "any" type from NavigationComponent
"any" cripples the typechecker, so it's best to avoid. It was introduced in #3392, but I don't think the intention was to keep it there.
* [flow] Remove `any` type from `createNavigator` return
And use objects with spread sub-types instead of unions for `React$ComponentType` type param
This really is not ideal but it's an upstream bug on react-native Android
that we can't work around. Users may experience other unexpected behavior as a
result of this upstream bug.
Previously we had been emiting an action event with a null state when the router handles the action by returning null from getStateForAction.
- Fixes the case of null state getting emitted
- Renames a few things for clarity
- Refactors conditionals to read easier
- Comments to explain intent
