Recommended patterns for menus and dialogs

[brentvatne]

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.

[dantman]

As I'm developing an app more and more using React Navigation I'm strongly leaning towards modals (menus and dialogs) being something StackNavigator supports.

• Handling menus and dialogs as part of params is insufficient. There are a variety of reasons one may want these separate, shared, or otherwise not polluting routes. And these grow as apps get bigger.
• Because of my need for a Drawer, screens above the drawer, and a modal StackNavigator for full-screen dialogs I already have a terribly deep and convoluted route tree. And I can say for certain that having separate navigators to handle different types of routes just makes things more complicated than they need to be.

So rather than dialogs and modals being a separate navigator I think it's better for StackNavigator to be able to handle the key points of dialogs/menus/modals/overlays:

• Routes that show the previous route in the stack below them.
• Overlay routes that don't affect the header, and.
• Routes that have a different transition style.

[brentvatne]

cc @ericvicenti - I tend to agree with @dantman's assessment here

[ericvicenti]

I really think we should be careful about adding a million features to StackNavigator.. its already getting out of hand. I have more details on my thoughts here:

react-navigation/rfcs#15