cc @ericvicenti

https://reactnavigation.org/docs/handling-iphonex.html
Related: react-navigation/react-navigation#3173

About order of navigationOptions. From the code, the order of overwritten is StackNavigatorConfig -> Component's static config -> RouteConfigs

This is a general question to all who are using react navigation, there is no documentation as to navigate to particular screen when user receives a notification

export const createRootNavigator = (signedIn = false) => {
  return StackNavigator({
      Login: screen: Login,
      Welcome: screen: Welcome,
      Loading: screen: Loading,
      SignedIn: screen:  SignedIn,
    });
};

export const SignedIn = TabNavigator ({
    Home: screen: HomeNavigation, 
    FeedBack: screen: FeedBackNavigation, 
    Search: screen: SearchNavigation, 
    Me: screen: ProfileNavigation,  
});

I am using 'react-native-fcm' to receive the notification when app is in foreground or closed. How should I structure the code to navigate to specific screens upon receiving notification?
Shall I subscribe to onNotification in every screen and then navigate to specific screen or have it at a centralized place? Has anyone tackled this before? sample code would be great

https://snack.expo.io/@react-navigation/custom-header-title-component
is the exact same as
https://snack.expo.io/@react-navigation/overriding-shared-header-styles

I believe https://snack.expo.io/@react-navigation/custom-header-title-component needs to be changed.

Hi, I noticed a discrepancy between the documentation and implementation of keys used for navigation, for example in the case of navigating backwards from a specific screen in the stack using goBack(key). The documentation, especially the code examples, make it seem like the key is the route name, however this is not the case and does not work. The documentation should be updated to reflect this, currently it is very misleading and the code examples provided do not work in practice.

Should have docs for new state persistence stuff

Be sure to include any limitations/bugs

I assume that the intended functionality was actually to link to the react-navigation repo, not GitHub itself. If so, I can submit a PR

Followed the instructions and yet:

Custom header:

const stackNav = StackNavigator({
    shiftsList: {
        screen: ScreenShifts,
        path: 'list',
        navigationOptions: ({navigation}) => ({
            header: <Titlebar showSettings={true} showNotificationCenter={true} navigation={navigation}>
                <ShiftToggler />
            </Titlebar>
        }),
    },

Wrapping the TabNav with SafeAreaView solves this but introduces a huge bottom margin. The TabNav is probably wrapped internally with SafeAreaView.

Wrapping the ScreenShifts with SafeAreaView does not solve this.

Any ideas?

react-navigation/react-navigation#288 (comment)

Can the documentation be updated to explain about route keys. Various parts of the API (Reset, Back) refer to them. However, there is no description of what these are or how they are set on the routes.

react-navigation/react-navigation#3008

Hello,

I am really new to this library and working on my app to replace old deprecated navigator with this one.

I got stuck when i need to verify authentication with deep linking.
May be we can put it in the docs on how to handle authentication flow with deep linking.

Thanks
D

react-navigation/react-navigation#3692

Seems like a reasonable thing to document

My related StackOverflow question is at https://stackoverflow.com/questions/48830648/how-to-define-a-route-and-then-create-a-simple-crosslink-to-that-route

How do I simply define/register a route such that I can call navigation.navigation('Someroute')? And how do I do this without an approach like StackNavigator or TabNavigator that also impacts the UI?

Is it possible in React Navigation to simply load a screen (component) according to a route?

Thank you.

• "Dynamic" options in tabs
• Dynamically hide tabs
• etc.. we can pick a lot of them from the feature request board and link to it as well

This has some people pretty frustrated and rightfully so as we don't indicate upfront anywhere that they will run into blockers on this. See: react-navigation/react-navigation#717

Is there a public API for jumping to some path, like what happens when the app is opened by a deep link? would it just be Linking.openURL? https://github.com/react-navigation/react-navigation/blob/c72b44ce104e5fbeb67624c44b792eca82285119/src/createNavigationContainer.js#L75-L84

Documentation for transitionConfig mentions:

take a look at TransitionConfig in type definitions

The link to type definitions is dead. Where would I find a reference to the default transitionsConfig?

Moved over from react-navigation/react-navigation#3003
@spencercarli came up with this solution: https://snack.expo.io/SyJKMkFUM
We might need to change the API a bit to make it cleaner but we can document this approach for now!

• If you're suggesting a change/improvement, tell us how it should work

It would be great to get documentation done for this "open modal from tab bar" layout. I've seen it asked a bunch of times in different places as it's a very common/popular requirement.

While not as helpful as writing documentation myself, here are some of the places this was asked, to show it would be useful to have it in the official docs:

• https://stackoverflow.com/questions/46725173/react-navigation-tabnavigator-show-modal
• https://stackoverflow.com/questions/42731093/how-to-push-a-modal-screen-using-reactnavigation
• https://stackoverflow.com/questions/45520898/react-navigation-and-modal-tab-item
• https://stackoverflow.com/questions/46725173/react-navigation-tabnavigator-show-modal
• https://stackoverflow.com/questions/46106117/tabnavigator-with-a-modal-popup-with-react-navigation-like-instagram
• https://stackoverflow.com/questions/42398911/how-do-i-make-a-tabnavigator-button-push-a-modal-screen-with-react-navigation
• react-navigation/react-navigation#525
• react-navigation/react-navigation#314
• react-navigation/react-navigation#1059
• react-navigation/react-navigation#1576
• react-navigation/react-navigation#2259
• react-navigation/react-navigation#1734
• react-navigation/react-navigation#770

@TomAtterton seems to have a solution in this issue

react-navigation/react-navigation#1576

He also left the same comment here:

https://stackoverflow.com/questions/42398911/how-do-i-make-a-tabnavigator-button-push-a-modal-screen-with-react-navigation

Anyway, best practice or not, Tom seems to have the only solution? Maybe he could give a slightly longer form answer and that can be used for docs? @spencercarli

I will try to write something up potentially.

Moved from react-navigation/react-navigation#1439

When I run the simulator, I am seeing a message suggesting that TabNavigator is deprecated. Is this true? Here is what I see in the terminal if I run the simulator with react-native run-ios:

9:19:29 AM: Finished building JavaScript bundle in 8834ms
9:19:34 AM: TabNavigator is deprecated. Please use the createBottomTabNavigator or createMaterialTopNavigator instead.
- node_modules/react-navigation/src/react-navigation.js:52:6 in TabNavigator
* App.js:50:17 in <unknown>
- node_modules/metro/src/lib/polyfills/require.js:213:12 in loadModuleImplementation
- node_modules/react-native-scripts/build/bin/crna-entry.js:7:11 in <unknown>
- node_modules/metro/src/lib/polyfills/require.js:213:12 in loadModuleImplementation
- node_modules/metro/src/lib/polyfills/require.js:140:45 in guardedLoadModule
* null:null in global code

The website documentation has a section on "Opening a Full Screen Modal" (here).

The method described is to have two child Stack Navigators with a shared parent. The children are created with mode: "modal" and mode: "card", respectively.

Given this setup, let's assume a user opens an app to a card Screen. As soon he navigates to a modal screen, wouldn't the modal StackNavigator contain an unwanted screen at the root of its stack -- the screen that StackNavigator created by default as the initial route? Of course it's possible to provide an initialRouteName, but in this scenario, it doesn't make sense to do so. The modal navigator's screens are not meant to be shown in succession, and hence, this navigator has no conceptual initial route.

Is there a way to address this that I am missing? It seems like the documented approach would create problems with back behavior given the existence of the initial screen at the root of the modal StackNavigator.

While going through the documentation I found that drawer navigation is lacking snack expo example, unlike other navigation.
I know that it is obvious at that point on how to use the navigation but I think it would be of great help if there was a working example that we can edit on the fly.

Thanks.

Explain that we only support a few of the possible combinations:

Stack->Tabs->Stack
Stack->Stack->Tabs
Drawer->Tabs->Stack
Drawer->Stack

For example, we do not properly support putting drawers inside of a stack: react-navigation/react-navigation#374

react-navigation/react-navigation#705

react-navigation/react-navigation#2725

What limitations do we have around this?

For example, react-intl uses context: react-navigation/react-navigation#2770. @satya164 gives a very good answer here

We expose routers independently from react-navigation, but they aren't documented

• StackRouter
• TabRouter
• DrawerRouter
• SwitchRouter

Hi. In my team we’ve struggled to implement conditional child navigation, where a branch of the navigation depends on user data (e.g. data in Redux and/or received from an API). In pseudo-code:

const Section1Default = StackNavigator(/* Some screens */)
const Section1Onboarding = StackNavigator(/* Different screens */)

const RootNavigator = TabNavigator({
  section1: Section1Default OR Section1Onboarding,
  section2: …,
  section3: …
})

The idea is that when clicking on a specific tab, the user should see either a series of "onboarding" screens or the feature’s screens. (Both options are navigators themselves, but could be single screens too.)

@brentvatne & @ericvicenti Do you think that’s a use case worth addressing in the docs?
I think I could contribute a page section or a page on this, but I’m not sure what solution to offer.

So far we’ve only found hackish workarounds, such as: a wrapper component which has a StackRouter with the two navigation branches, and which navigates to the correct branch on willFocus. It works, but the trick falls short when using the Android back button.

Copied from react-navigation/react-navigation#1315

The preferred pattern for handling dialogs and menus don't seem to have been discussed yet.

Menus that open from a menu button are a fairly common pattern.

I can see 2 possible ways they might be implemented:

• As part of params: Menu is part of a scene's children, headerRight uses setParams to set a param indicating the menu is open and that param is passed to whatever prop on the menu indicates it is open. Closing the menu is another setParams. One would have to either use <Modal /> or manually register a BackAndroid (now BackHandler) to handle the Android "back button closes menu instead of navigating backwards" pattern.
• As a navigator: Menus are implemented as a part of a MenuNavigator (or maybe a ModalNavigator), the navigator is used in place of the screen for a route in your {Stack,Drawer,Tab}Navigator and accepts one route that is the normal screen and other routes are menus. Menus are opened using navigator.navigate('MenuName') and exited using navigator.goBack().

Dialogs are another modal type to consider (given the drawer is already considered a navigator).

Drawers make less sense as part of props but there are still 2-3 patterns I can think of for them:

• A DialogNavigator: Just like the MenuNavigator/ModalNavigator I described a DialogNavigator would be used in place of a normal screen and allow navigator.navigate to open a specific dialog from the associated screen.
• A top-level DialogNavigator: Instead of taking place of a deeper screen, the DialogNavigator would be top-level like the DrawerNavigator is. This would allow it to easily sit on top of everything else and put dialogs on top. Dialogs would become global, which could be a pro or a con depending on the app.
• As part of StackNavigator: Instead of a whole separate navigator StackNavigator would be modified to support modals (routes that can have no headers of their own, are drawn transparently over top of the other screens, and have a separate transition type). From the nesting and navigation perspectives this is a little simpler. There is no extra nesting of navigators that could make navigation.navigate calls more complex in any scenario, opening a dialog by navigating to it is simple, and closing a dialog via navigator.goBack() is built-in. Also this would already handle full-screen dialogs pretty well and handle the tablet+mobile environment where a route may be a full-screen dialog with a header in the stack route on mobile but be a dialog on a tablet without a header.

Full-screen dialogs themselves are probably a separate more precise discussion.

I think we need to still do more thinking about the right way to handle this in the library. Blocking a second action is wrong (hard to understand when you actually want to do this why it didn't work) and our current solution of using idempotent pushes (provide a key) isn't as ergonomic as it could be.

There's this gist I just shared. It's based on a running project I'm working on.

https://gist.github.com/sidferreira/72e17d29b224ca93cf86901ed1ceb032

Feel free to link or copy.
In any way, a mention will be acceptable

Suggestions are welcome

ps: I still tweaking it, so, if you prefer, I can beep when I feel it a bit more "done"

react-navigation/react-navigation#2932
react-navigation/react-navigation#2870

Hey people, especially @ericvicenti, @brentvatne

First of all I would like to tell you that I'm extremely grateful for your work, I know that open-source projects are based on developers free-time, and this doesn't force to give any guarantees.

I'm also a member of this community. I just want to improve the software and make him more accessible to people that are using it.

What is that about ?

It's been 3 weeks that I'm stuck for building a huge application for my client working in the medical (great company). My brain is boiling, I tried to turn the problem in all directions. I always face the failure. I've been forced to hack the library and the behavior in many way but I can't escape anymore and I would like to do the right things to have a top quality product.

Samples & even demonstration are cool, but I can't find anywhere (and god knows I tried everywhere to ask some help and tried so many things) to render a complete routing for a great application.

I would be really graceful to you if you can light me up, also the community and I would be really pleased to improve the documentation from the point of view of a man that is not part of the library core (and you can trust me this is important that the documentation is from that point of view...)

Below is a representation of my application screens as I structured them in my mind (I might be wrong):

Application Screen Tree

• ROOT (Redux aware with nav helpers)
  • Anonymous (I presume StackNavigator)
    • Onboarding (Stack)
    • AnonymousSplash (Contain button to go back to onboarding, if not first app launch, Go to login and go to signup)
    • Login (This should trigger moving to the other part)
    • Signup
  • Authenticated (Tab Navigator)
    • Home
    • Journal
      • JournalOnboarding (A first step that initialize the journal)
      • JournalReadyNavigator (Another tabNavigator that display this time a top Tabnavigator)
  • Modals (A collection of things that swipe from bottom as fullscreen as described in the current doc)

Looks simpIe on the paper, right ? But not so easy in fact...

This is just so hard to represent and make it work... WHY ? What is the purpose of such a library if we can't use it for great companies that require complexe UI. For you consideration, you concurrents already show a way to deal with that case such as HERE.

What I would like you to light-up

What I would like you to do is the following:

Can you provide an (or some) examples that shows :

• First time login / account creation, along with an onboarding screen ? That use a StackNavigator.
• Authenticated area that use a TabNavigator
• Conditional rendering on both depending on the login state, INCLUDING killing and restart application and checking the redux state for a given JWT (or something like) token to determine if we are already connected.
• In a generic way, how to achieve conditional router rendering without broking navigation state. Redux connect can be an issue ? Tell us about that.

All of this without broking the navigation state because I need to both:

• Track EACH screen transitions.
• Handle a back button logic in the less place possible, using my own algorithm that browse nav state recursively.

I think this is a top priority, not only because I need it but because if people can't understand how you were thinking when you designed the library, they won't be able to realize great things using it and will probably go somewhere else to achieve what they have to...

I wish you a great day,
Best regards.

Andréas

PS : If I can help you for that in any way, just tell me.

Using navigation events. See react-navigation/react-navigation#2803

Linear gradient, translucent, transparent, etc..

react-navigation/react-navigation#716

Is there any plan to support multilingual for the website? I guess it'd be very useful if we do.

Moved from react-navigation/react-navigation#3890

Using multiple Navigators inside a DrawerNavigator, where the subnavigators shared a route name, led to unexpected (undocumented) behavior

Context

I was an early user of @expo/ex-navigation, and have recently been upgrading to react-navigation. I came across some faults in either the DrawerNavigation documentation or in the general mental framework of react-navigation.

Current Behavior

When nesting navigators inside a DrawerNavigator, duplicated route names behave unexpectedly (in my mental model).
Expo Snack repro

const WidgetStack = StackNavigator({
  Widget: {
    screen: WidgetScreen,
  },
  // This is very easy to get wrong, it is not clear in the Drawer documentation
  // that this route name should be distinct.
  Settings: {
    screen: SettingsScreen,
  },
});

const SettingsStack = StackNavigator({
  Settings: {
    screen: SettingsScreen,
  },
});

const DrawerApp = DrawerNavigator({
  Widget: {
    screen: WidgetStack,
  },
  Settings: {
    screen: SettingsStack,
  },
}, {
  initialRouteName: 'Widget',
});

When tapping on the "Settings" drawer item, I expected the currently selected "tab" in the drawer to be "Settings", I expected no routes to be "pushed" onto my stack navigator. Instead, the "widget" tab stays selected, and a settings route is pushed onto the WidgetStack.

There were no pieces of documentation to warn me of this behavior, and it was actually very difficult to even tell this is what was happening (it was much easier when I decided to build the minimal repro).

My current mental model

My mental model for react-navigation was previously that each nested navigator was a "subtree". With that model, I saw no issue with a duplicated route name.

               DrawerApp
	      /         \
	  WidgetStack    SettingsStack
          |     |	       |
	  /      \           Settings
	Widget   Settings

I'm not here to debate whether this is the correct model, but a simple piece of documentation would have saved me about an entire day :(

I would be happy to submit a PR to address this, but it appears with the 2.0 push, this might be out of date, and furthermore - I am not sure if my current model is correct enough to even write docs.

Doc
This Doc is wrong.

ComponentWillMount and ComponentWillUnmount aren't guaranteed to be called when navigating between screens leaving extra listeners.

Please see this issue #298 and this issue which was closed because of this issue #51

react-navigation/react-navigation#3143 shows that there is some confusion about nesting navigators as screens. This will probably require improving the API to make this more ergonomic, but for now we should at least make this super clear.