[Enhancement] Support for Series Navigation within Shell Tabs

[tomeverin]

Summary

Regarding TabBar navigation: if there are multiple ShellContent Items within a Tab, this automatically results in a top TabBar so the user can navigate between them. This represents ShellContent items in parallel. I'd like to be able to have ShellContent items in series within a single Tab.

That's the idea up for discussion - the rest of this post is one possible way it could work. The attraction is that depth of navigation (e.g. third level routing) could then be described in the same convenient xaml format. That's what I like most about Shell.

API Changes

An example of the XAML for TabBar as it currently stands (note Tab for Page2 in particular):

<TabBar Route="tabs">
        <Tab Title="Page1" Route="page1" Icon="page1.png">
            <ShellContent ContentTemplate="{DataTemplate local:Page1}" />
        </Tab>
        <Tab Title="Page2" Route="page2" Icon="page2.png">
            <ShellContent Route="page2A" ContentTemplate="{DataTemplate local:Page2A}" />
            <ShellContent Route="page2B" ContentTemplate="{DataTemplate local:Page2B}" />
        </Tab>
        <Tab Title="Page3" Route="page3" Icon="page3.png">
            <ShellContent ContentTemplate="{DataTemplate local:Page3}" />
        </Tab>
</TabBar>

The following illustrates my proposal (note Tab for Page2 in particular):

<TabBar Route="tabs">
        <Tab Title="Page1" Route="page1" Icon="page1.png">
            <ShellContent ContentTemplate="{DataTemplate local:Page1}" />
        </Tab>
        <Tab Title="Page2" Route="page2" Icon="page2.png">
            <ShellContent Route="page2A" ContentTemplate="{DataTemplate local:Page2A}">
                <ShellContent Route="page2B" ContentTemplate="{DataTemplate local:Page2B}" />
            </ShellContent>
        </Tab>
        <Tab Title="Page3" Route="page3" Icon="page3.png">
            <ShellContent ContentTemplate="{DataTemplate local:Page3}" />
        </Tab>
</TabBar>

In the second example, I propose that page2B would be:

• Accessed by route "tabs/page2/page2A/page2B"
• Not as a modal; the bottom tab bar should still visible
• Page2B is pushed atop Page2A
• When navigating between bottom bar tabs, page2 persists with page2B as its content

Intended Use Case

Suppose a button click somewhere in the page1 tab should show Page2B, but it should do so in the context of the page2 tab. Calling GoToAsync("tabs/page2/page2A/page2B") would set the page2 tab active and also show Page2B as the content. The user could then still use the page1 tab bar button to return to the previous view.

This is useful where the ViewModel for Page2B is affected by functionality in other tabs.

This Behaviour Today

The only way I've found to produce this behaviour currently is:

1. User taps button in Page1 tab
2. GoToAsync("tabs/page2");
3. (Shell).CurrentItem.Navigation.PushAsync(Page2B);

This has worked really well so far, but it doesn't allow for the convenience of keeping my navigation hierarchy defined in a single place (i.e. AppShell.xaml)

[tomeverin]

Some of the route strings there might be wrong, but you get the idea I hope.

[PureWeen]

@tomeverin

This is definitely a scenario I would like to light up!!

What would the user see if your shell was defined like this?

<TabBar Route="tabs">
        <Tab Title="Page1" Route="page1" Icon="page1.png">
            <ShellContent ContentTemplate="{DataTemplate local:Page1}" />
        </Tab>
        <Tab Title="Page2" Route="page2" Icon="page2.png">
            <ShellContent Route="page2A" ContentTemplate="{DataTemplate local:Page2A}">
                <ShellContent Route="page2B" ContentTemplate="{DataTemplate local:Page2B}" />
            </ShellContent>
            <ShellContent Route="page5A" ContentTemplate="{DataTemplate local:Page5A}">
            </ShellContent>
        </Tab>
        <Tab Title="Page3" Route="page3" Icon="page3.png">
            <ShellContent ContentTemplate="{DataTemplate local:Page3}" />
        </Tab>
</TabBar>

Would the top tabs still be visible?

I have some thoughts around this I posted in the spec over here

#10804

Enable ShellElement navigation scenarios

Currently with shell you can only push ContentPages but the user should be able to push everything and anything.

This will also allow you to better articulate at what level you want a navigation to occur.

Right now whenever you push a ContentPage the NavigationStack is always relative to a bottom tab. Once we enable shell types to be pushable those can push at different levels

• GotoAsync("ShellContent")
  • This will set the NavigationContainer to the first explicit parent. So if you have top tabs it'll be relative to the top tab.
• GotoAsync("Tab")
  • This will Push how things are currently pushed. The navigation stack will be relative to the bottom tab
• GotoAsync("FlyoutItem")
  • This will push an entirely new main layout onto the stack

[tomeverin]

@PureWeen
#10804 looks great

Would the top tabs still be visible?

I think that the top tabs are intuitive for the parallel case only. Nested ShellContent, i.e. the series case, to me implies a "drill down" type experience which would be managed entirely by routing calls in the code.

The parallel case naturally suggests top tabs, I don't think the series case should come with any automatic UI.

[tomeverin]

@PureWeen

What would the user see if your shell was defined like this?

Sorry I missed the altered XAML.

In that instance:

• the top tabs would still be visible (for the parallel 2A and 5A tabs)
• there would be a series "drill down" experience inside the 2A tab
• e.g. routing to "tabs/page2/page2A/page2B" would result in:
  • 2B replacing the 2A top-tab content
  • 2B still in parallel with 5A (top-tabs unchanged)

That doesn't sound like a very nice user experience! But that type of flexibility will make Shell feasible as a complete navigation solution.

[PureWeen]

Cool!! I'm excited we're thinking along the same lines for this one
We are moving forward the Shell data structures to handle this type of scenario.

And this is definitely how I'd like this all to work

Once I get this PR merged
#9626

That'll start making stuff like this easier

[tomeverin]

That's great! Bright future for Shell.