* Isolate modules for uncontainerized navigators
* Clean up prop-types
* Fix warnings and web import friendlyness
* strip a flow
* Standalone provider/consumer navigation context
* export shallowEqual as module
* address various lint
# Conflicts:
# src/navigators/createStackNavigator.js
* Get tests to pass
Creating a new error makes the stack unreadable in sentry, because the stack is stringified when the error is cast to string to create a new one.
Is there another reason to do that ?
Alternative possible solution would be to add a method to be able to handle the error ourselves ?
This bug wasnt apparent until we fixed the transitioner to fully respect isTransitioning. The router did not handle this properly until now.
Enhanced a test to verify this in the future
* 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
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
