* Fixing iPad iOS 11 Tab Bar Bottom Behavior with changing widths via Multitasking
* Updating snapshot tests
* Changes per discussion in !3041
* Additional changes per discussion in !3041
* Changing to test for constrained height
* Additional changes per discussion in !3041
* Use Animated.View instead of View in SafeAreaView
This allows passing animated style properties in certain contexts, as previously supported.
* Update some test snapshots
`TabRouter.getStateForAction` has some code at the start to initialize an empty nav state before handling any action. This initialization is achieved by passing `INIT` actions to all child routes. However, the code strangely also passes these child routes the params that were given to the action. The initialization should be separate from the processing of the action.
* allow transition configuration between tabs
* we don't need to pass configureTransition to TabBarComponent
* Update TabAnimations.js
* Update TabNavigator.md
* 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
In React Fiber (React 16), strings are used for intrinsics like 'div' and 'View'. As a result, if you use a View as a screen in an academic experience, you get a red error screen. This PR prevents that from happening.
