* Add fbemitter, keep flow passing
* Begin support for event emitter
- Adds emitter to navigation prop
- Emits top level onAction event
- stub getChildEventSubscriber for child events
* Support navigationState.isNavigating
* Focus and blur events starting to work
- Navigation completion action wired up
- Event chaining logic built in getChildEventSubscriber
- Renamed onAction evt to ‘action’
* Wrap up events progress and testing
* Rename to isTransitioning and COMPLETE_TRANSITION
* rm accidental dependency
* Suppoert event payload type
* Update to React Native 0.50
* Type Promise used in PlatformHelpers.web.js
* Move $FlowFixMe in CardStack.js
The line number Flow is using for this error changed. The underlying problem has not, but I don't have time to fix it now unfortunately.
* Type TouchableItem's children prop as React.Node
This was my bad. `React.ChildrenArray` should only really be used in the case of having multiple of the same type of child.
* Type HeaderTitle's children prop as React.Node
Same as last commit.
* Add assertion in StackRouter that StateUtils.indexOf returns valid index
Flow doesn't realize that `StateUtils.indexOf` is guaranteed to return a valid index, so we use `invariant` to assert it.
* Remove unused type DrawerNavigationState from TypeDefinition
* Remove unused type parameter T in DrawerView
* Type NavigationStateRoute as NavigationLeafRoute & NavigationState
* Don't constrain generic action types to NavigationAction
By constraining to subtypes of `NavigationAction`, we actually are requiring that any router satisfying our type constraints has to take all of the `NavigationAction` types. Instead, we want to say that it will only take some of them. Changing the types here to be inferred.
* Fix types of NavigationScreenProp and withCachedChildNavigation
1. `NavigationScreenProp` needs to have its type parameter annotated with a `+` to actually indicate covariance on that type parameter, apparently
2. `withCachedChildNavigation` needs to thread through more-specific `NavigationState`s, and right now it just discards that specificity, which breaks `DrawerSidebar` because it needs a `NavigationStateRoute`
* Ignore website/build from Flow
* Fix type of DrawerItems activeItemKey prop
- Even when specified, it can be `null`
- Use a ternary expression instead of `x && x.param` approach
* Get rid of NavigationRouter & NavigationNavigator parameterization on NavigationAction
Since `NavigationRouter`'s `getStateForAction` functionality is a standard Redux reducer, it knows to forward on any actions it doesn't know how to deal with. We can widen the types of these functions to be `NavigationAction` without any negative consequence.
* Explicitly specify null navigationOptions in createNavigator
Not sure why, but Flow doesn't like us leaving it unspecified
* Fix createNavigationContainer/createNavigator/StackNavigator types
* Fix up flow types for TabNavigator and DrawerNavigator
* Properly type defaultContentComponent
* Fix more flow errors in createNavigationContainer
* Replace NavigatorProps with NavigationNavigatorProps
* Type SceneView's navigation prop as NavigationScreenProp<any>
There is an unavoidable* type problem here. A `NavigationComponent` is either a navigator with a `NavigationStateRoute` or a scene with a `NavigationRoute`. The navigation prop it gets passed must match the component's `NavigationState`. However, there's no way for us to say that "`this.props.router.getComponentForRouteName` will have a `NavigationNavigator` iff the corresponding `childNavigationProps` is a `NavigationStateRoute`".
The cleanest way to make this work is to throw an "any" specifically for the navigation prop's state type param.
* We could probably avoid it with sufficient refactoring. If the routers were charged with keeping track of `childNavigationProps` instead of leaving it to the views, they could return the child navigation prop and child `NavigationComponent` in pairs whose types were coupled.
* Pass in screenProps to NavigationComponent in NavigationPlayground's CustomTabs
Flow wants `screenProps` to be passed in here for some reason...
It cites `SceneView`, but that doesn't really make much sense to me. But this is some custom logic that most people aren't likely to run into, so I'm not gonna worry too much about it.
* Patch mismatch with react-native-tab-view type for now
* Use generic NavigationState in createNavigationContainer's _nav var
We made the NavigationState generic while #1313 added a new instance variable. This updates the new instance variable to be generic.
* Fix failing tests
