react-navigation/examples/SafeAreaExample/package.json

{
  "main": "node_modules/expo/AppEntry.js",
  "private": true,
  "dependencies": {
    "expo": "^23.0.0",
    "react": "16.0.0",
    "react-native": "^0.50.3",
    "react-native-platform-touchable": "^1.1.1",
    "react-navigation": "file:../.."
  },
  "name": "SafeAreaExample",
  "version": "0.0.0",
  "description": "Hello Expo!",
  "author": null
}
Safe area example (#2890) * Add SafeAreaEample for testing * Remove portrait default lock on SafeAreaExample and add a spacer between buttons 2017-11-02 18:12:11 -07:00			`{`
			`"main": "node_modules/expo/AppEntry.js",`
			`"private": true,`
			`"dependencies": {`
Update to react-native@0.50 and flow-bin@0.56 (#2998) * 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 2017-11-20 11:53:48 -08:00			`"expo": "^23.0.0",`
			`"react": "16.0.0",`
			`"react-native": "^0.50.3",`
Safe area example (#2890) * Add SafeAreaEample for testing * Remove portrait default lock on SafeAreaExample and add a spacer between buttons 2017-11-02 18:12:11 -07:00			`"react-native-platform-touchable": "^1.1.1",`
Update to react-native@0.50 and flow-bin@0.56 (#2998) * 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 2017-11-20 11:53:48 -08:00			`"react-navigation": "file:../.."`
Safe area example (#2890) * Add SafeAreaEample for testing * Remove portrait default lock on SafeAreaExample and add a spacer between buttons 2017-11-02 18:12:11 -07:00			`},`
			`"name": "SafeAreaExample",`
			`"version": "0.0.0",`
			`"description": "Hello Expo!",`
			`"author": null`
			`}`