* 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.
* Fix default width of drawer
Current implementation is simplified / broken.
- The drawerWidth doesn't work for tablets, the drawer becomes massively large
- Header size changes (and thus drawer width changes) in landscape mode on iOS are not accounted for
- An incorrect 64px header size is used for iOS (this includes the status bar height that doesn't belong in the calculation)
Implement a default drawerWidth as a function that follows the Material Design spec closer:
- Screen width - header height
- Use the correct iOS app bar height in portrait and landscape mode
- Drawer max height of 280 on mobile and 320 on tablet
* Update snapshot for drawer width change
* Move SafeAreaView out of DrawerNavigatorItems to DrawerSidebar.
The SafeAreaView was breaking custom contentContainers in drawers. Fixes#2963.
* Fix SafeAreaView in DrawerItems and Drawer contentComponent
* Fix flow error and tests.
* Update Drawer documentation with SafeAreaView recommendation. Remove one of the examples for `contentComponent`.
* Put the View back.
* Update snapshot.
this react-native error has no adequate stack, and i waste 4 hours for juggling pieces, until i get the idea to trace error by myself and finded this bug
* add 2nd params argument to StackRouter.getActionForPathAndParams
It still falls back to parsing the query string if no params argument is provided, but now TabRouter.getActionForPathAndParams which might call StackRouter.getActionForPathAndParams with a 2nd params argument will work correctly.
In addition, if called directly (as may be the case in apps with custom deep-linking needs [which is my primary case]), it will function correctly without users having to build a query string.
This also solves the problem that deserialization of query strings is currently implemented without support for cases like nested arrays within the query string.
* Update StackRouter.js
