d1c434b54c
* Update root package to react-native@0.49 and flow-bin@0.53
* Update NavigationPlayground package to react-native@0.49 and flow-bin@0.53
* Update ReduxExample package to react-native@0.49 and flow-bin@0.53
* flow-typed update (code-gen)
* Find-and-replace old types with new types
- `React.Element<*>` as the result of a render function is now `React.Node`
- `ReactClass<T>` as the type of a Component is now `React.ComponentType<typeof T>`
- `extends React.Component<DP, P, S>` is now `extends React.Component<P, S>`
- `React.Children<*>` as the type of a children prop is now `React.ChildrenArray<*>`
- Refs are now typed with `React.Ref`
There are also several tiny typo fixes in here.
* Avoid assuming state is NavigationRoute in addNavigationHelpers
For the root, top-level Navigator, the state is a simple `NavigationState` (with no route info) and we still use `addNavigationHelpers` for it. We can't assume `navigation.state.key` is accessible for this type, so we need to do runtime checks here.
* Fix type of NavigationScreenConfig
`navigationOptions` was incorrectly typed
* Give createNavigationContainer's State a type parameter
We want to be able to specifically type this guy so we can use specific NavigationState for things like the Drawer views without having to do runtime assertions about the state type
* Fix typing of NavigationAction
First of all, `NavigationAction` was being used as two different types, so I had to create the new `PossiblyDeprecatedNavigationAction` and add it as a type parameter everywhere. Second of all, generics and implied types were being used far more than they need to be, and they're hard to work with because Flow doesn't really explain things well when they go wrong.
* Make sure children scenes of CardStack have NavigationProp typed with NavigationRoute
CardStack's `NavigationScreenProp` is typed with `NavigationState`, but the children need `NavigationRoute`. Flow gets confused by the spread operator, even if the individual property is replaced later, so we need to explicitly list each property individually (just `dispatch`, actually).
* Allow prevTransitionProps parameter to be nullable
* Allow prevTransitionProps parameter to be nullable
* Narrow down a couple type parameters
* Move NavigationStateRoute cast to within Component.router check in createConfigGetter
* Update withCachedChildNavigation so it's typed correctly with React.ComponentType
* Add a $FlowFixMe for displayName
`React.StatelessFunctionalComponent` is missing `displayName` before Flow 0.54.0
See de37062ea2
* Make TouchableItem's onPress prop optional
`HeaderBackButton` can pass in an undefined onPress, and the React Native `Touchable*` components allow it too
* Simplify withCachedChildNavigation and get rid of generics
The generics don't help us here and they make the types more confusing
* Redefine NavigationComponent as direct intersection
The new type is technically identical to the old type, but Flow is confused by the old type...
* Save router to local var before checking createConfigGetter
Flow seems to think Component.router can change after the check
* Fix DrawerSidebar's navigation prop's type
In order for us to be able to generate a childNavigationProp, the original navigation prop has to have a NavigationState state.
* Colocate action.key check with action.type check in getStateForAction
For some reason, Flow thinks `action` can change sometime after `action.type` is checked. As a result, it's not properly concluding that `action.key` should exist. To avoid this, we pull `action.key` out immediately after doing the `action.type` check.
* Use bounded polymorphism to pass down all props in withCachedChildNavigation
Also makes sure the injected props are specified first in the union
Also removes an unused `eslint-disable-line` in `getScreenForRouteName`
* Make TabRouter's getComponentForState return NavigationComponent
`NavigationScreenComponent` is a subtype of `NavigationComponent`, but it's not clear that `getComponentForState` always returns a `NavigationScreenComponent`, as `getScreenForRouteName` returns `NavigationComponent`
* Define NavigationComponent's props using NavigationNavigatorProps
Right now the types ask Flow to infer the types of `NavigationComponent`'s props. (`NavigationComponent` is the union of `NavigationNavigator` and NavigationScreenComponent.) Instead, we type the props as subtypes of `NavigationNavigatorProps`, so we can properly access those props without type errors. We used bounded polymorphism in `createNavigationContainer` and `createNavigator` to pass down these props. We also explicitly type the action in `createNavigationContainer` so we can properly pass in a `NavigationInitAction` to the dispatch function.
* Parameterize NavigationTabRouterConfig
`NavigationTabRouterConfig` doesn't always take `NavigationTabScreenOptions`; sometimes, it takes `NavigationDrawerScreenOptions`.
* Make all NavigationOptions Exact types
We're seeing weird behavior when these are merged together. By making them Exact types, we make types don't get mangled when they're unioned.
https://flow.org/en/docs/types/unions/#toc-disjoint-unions-with-exact-types
* Silence errors in tests
These errors are unavoidable since we can't type the precise shape of a particular `NavigationState`.
* Include NavigationSetParamsAction in NavigationTabAction
`TabNavigator`'s `getStateForAction` definitely takes `NavigationSetParamsAction`.
* Explicitly list router as void in NavigationScreenComponent
This is so Flow knows that if a `NavigationComponent` has a `router` property, then it is definitely a `NavigationNavigator`.
* Fix website app navigator's type
* Fix createDocPage type in App
In an earlier commit I attempted to fix the types here, but I incorrectly read it as returning a navigator when it just returns a screen. For some reason the error didn't immediately show up.
* Fix NavigationComponent types
Five changes:
1. No longer parameterizing the props of `NavigationComponent`; directly specifying as `NavigationNavigatorProps`
2. Specify the two distinct kinds of route types (leaf and state) directly in `NavigationComponent`
3. Have `SceneView` directly take `NavigationComponent` and allow inferring of `NavigationSceneProp` type
4. Have `CardStack` directly take `NavigationComponent` as well
* Allow Flow to infer `NavigationAction` type in `createNavigator`
* Silence Flow in router code that handles navigator sub-routes
There's no way for us to tell Flow that routes that correspond to navigators should be `NavigationStateRoute`s
* Allow DrawerSidebar to take a null contentComponent
The way `DrawerNavigator` is set up, it's possible to pass in a null `contentComponent` in the config.
If somebody want to do this, we'll just make the `DrawerSidebar` not appear altogether. This is simpler than splitting the types so there's a possibly-unspecified one for the user input, but a definitely-specified one in `DrawerSidebar`.
* Specify missing screenProps prop in DrawerView
* Thread full NavigationStateRoute in to DrawerSidebar
This requiring making `withCachedChildNavigation` use bounded polymorphism to thread the `NavigationStateRoute` through instead of downgrading it to a `NavigationState`
* Make NavigationStateProp's state prop covariant
This means that `NavigationStateProp<NavigationStateRoute>` will be a subtype of `NavigationStateProp<NavigationRoute>` and `NavigationStateProp<NavigationState>`
* Silence Flow's complaints about a route not being a NavigationStateRoute
As mentioned in previous commits and in the comment, there is no way to type a specific navigation state shape, so we have to cast it and silence Flow's complaints.
* Get rid of style prop in CardStack
It looks like at some point, it was possible to specify a `style` prop that got passed all the way down to `Header`, the `TransitionConfig`'s `screenInterpolator`, and `Transitioner`. Doesn't look like we're using it anywhere, and there's a todo saying to remove it, and it's causing a type error.
* Infer type of options instead of using a subtype of {}
I think this has to do with {} allowing for unsealed objects. I'm not 100% sure, but this fixes 4/6 of the remaining errors!
* Fix two type errors in NavigationPlayground
One was just requiring an outdated type (`React.Children` instead of `React.ChildrenArray`), and the other was getting confused regarding types because of a spread operator.
* Use a covariant property to simplify withCachedChildNavigation's InputProps
This doesn't reduce any errors, but it's a bit simpler and cleaner.
* Silence last two Flow errors regarding withCachedChildNavigation injecting childNavigationProps
These are the only two errors I haven't been able to figure out at all. If I had more time I'd try and figure out the simplest case and report it to the Flow team, but I've been working on this for a week already and have to move on.
The issue at hand is that `withCachedChildNavigation` injects `childNavigationProps`, but Flow doesn't see this and thinks it needs to be specified by the view component. We're using the HOC pattern suggested by the Flow docs, and I've tried several other patterns to no avail.
* Use stock react-native instead of Expo's in NavigationPlayground
Expo's causes Flow errors, and apparently this is normal practice because the person who switched us to Expo did this too.
* Silence react-native-gesture-handler Flow errors in NavigationPlayground
Expo requires this package, but it causes Flow errors.
* Fix index check in DrawerSidebar
Silly me, falling for the typical "0 is falsey" problem...
* Rework deprecated action tests
In an earlier commit I moved the `NavigationActions.mapDeprecatedActionAndWarn` out from `getStateForAction` and into `createNavigationContainer`'s `dispatch` function. The tests need to be reworked to support this, as they were previously calling `getStateForAction` directly. I don't imagine any users are calling `getStateForAction` directly.
* Re-record two snapshots
The changes in these snapshots are by design and don't affect anything.
* Infer type of options in NavigationScreenConfig
The issue is that sometimes we include options for different navigators in a single blob.
* Infer types of action and options in createNavigationContainer
Particulary helps with Options. Makes the types more specific and gets rid of an error that only shows up when using the library
* Don't use generics for NavigationState in createNavigationContainer
There's no particular reason for having those generics there, since there's no way we'd be able to get Flow to understand the exact shape of particular navigation states anyways. This fixes a bug when integrating this version of the project into my repo.
* Move ReduxExample to react-native@0.49.3 instead of custom Expo version
React Navigation 
Learn once, navigate anywhere.
React Navigation is born from the React Native community's need for an extensible yet easy-to-use navigation solution based on Javascript.
React Navigation is the result of a collaboration between developers from Facebook, Expo and the React community at large: it replaces and improves upon several navigation libraries in the ecosystem, including Ex-Navigation, React Native's Navigator and NavigationExperimental components.
Installation
Since the library is a JS-based solution, to install the latest version of react-navigation you only need to run:
yarn add react-navigation
or
npm install --save react-navigation
Get Started
To learn how the library work, head to the introduction on the website for a quick tutorial that will cover all the basics - or try it out our expo demo.
Advanced guides
React Navigation API
Community contributions
A lot of developers poured their knowledge in blog posts, and other repos - we will try to keep here a list of tutorials and resources to help someone who wants to learn about React Navigation and techniques to handle navigation effectively.
Introduction to the library
Basic Tutorials
- Basic ReactNavigation Example App and Tutorial
- Understanding Navigation in React Native
- Comprehensive routing and navigation in React Native made easy
- Replace a Screen Using React Navigation
Intermediate Concepts
- Using React Navigation and Redux in your React Native Application
- React-Navigation, complete Redux state management, tab-bar, and multiple navigators
- Custom Drawer with React-Navigation in React-Native
- React Navigation Drawer - a tutorial series
Advanced Topics
Comparisons and Discussion
- Migrate from ExNavigation to React Navigation
- Playing with React Navigation and Airbnb's Native Navigation
- How we restructured our app with React Navigation
- What’s Happening with Navigation in React Native?
Example Projects
Libraries
FAQs
When is version 1.0.0 going to be released?
As soon as all the tasks here have been completed. You can read more about it in the blog.
(in the meantime, you can find the changelog for every release here)
I'm having troubles using the library, what can I do?
Head to the issues and do a quick search: if you think you are experiencing a bug chances are somebody already opened an issue for it. If instead you are having more general problems, use Stack Overflow - which is better suited and helps keeping the Issues section of the repo clean. Alternatively you could join the Reactiflux community on Discord where there are React Native and React Navigation channels with helpful people who might be able to answer you.
You should only open a new issue if you believe that you are experiencing a bug or have a feature request, and please follow the dedicated template - it will help everyone helping you (and may get closed if it doesn't).
My app is really slow!
We are aware that the performances can be improved - we will work on this (keep an eye on the roadmap linked above). In the meantime, please refer to these few issues for specific information regarding:
In particular, refer to this comment (and the one after that) to learn more about how you can try improving the performance of your code.
How can I help?
Glad you ask! This library is a community effort: it can only be great if we all help out in one way or another 😄 . If you feel like you aren't experienced enough using react navigation to contribute, you can still make an impact by:
-
Responding to one of the open issues. Even if you can't resolve or fully answer a question, asking for more information or clarity on an issue is extremely beneficial for someone to come after you to resolve the issue.
-
Creating public example repos of navigation problems you have solved.
-
Answering questions on Stack Overflow. Alternatively, asking questions on Stack Overflow instead of opening an issue.
-
Answering questions in our Reactiflux channel.
-
Providing feedback on the open PRs.
If you feel brave enough you can submit a PR: follow the Contributors guide to find out how. If you don't know where to start, check the ones with the label Type: Good First Task - even fixing a typo in the documentation is a worthy contribution!
Is this the only library available for navigation?
No: there are some other libraries - which, depending on your project, can be better or worse suited for your project. They differ in the approach and implementation from react-navigation, but share the common goal of helping you create a good React Native application; you can find a general round up in the React Native docs.
Can I use this library for web?
This library originally planned to support web too - but at the moment it is not a priority for v1.0; a lot of work is necessary to reach it as-is and we had to freeze this support (consider it "experimental").
Code of conduct
This library has adopted a Code of Conduct that we expect project participants to adhere to. Please read the full text so that you can understand what actions will and will not be tolerated.
License
React-navigation is licensed under the BSD 2-clause "Simplified" License.