More navigation models?

[arkivanov]

There are Child Stack and Child Overlay high-level navigation models. There is also lower-level Generic Navigation which can be used as it is, or to create additional navigation models on top (e.g. both Child Stack and Child Overlay use it). Let's collect here use cases and feedback for additional navigation models, so most useful could be added to the library.

Please keep in mind that Decompose tries to be minimalistic with its API surface, so only reasonable and useful things should be added.

Let's do one idea per message, so we could discuss each in its own thread.

[marcguilera]

Pager: Similar to a stack but more like an indexed list. To simplify things that list may be static as a general use case is for onboarding slideshows, etc.

[arkivanov]

Thanks! This one looks useful. One point to consider - the amount of items can be large (e.g. 100/1000). Perhaps the API should support something like createdSpan argument, so only the specified amount of components around the selected index are created. It also makes sense to support changing children.

Let's gather some feedback and use cases for now.

[Shabinder]

#346
I think kinda related.

[arkivanov]

I have created a Discussion with API design for pager - #363.

[arkivanov]

An experimental version has been released in 2.0.0-beta-01.

[marcguilera]

Carousel: Very similar to a pager but I mention it separately as usually don't take the whole screen and maybe the developer we wants to be able to display 1..N items per slide depending on the screen size which impacts the NavState.

[malliaridis]

@arkivanov Would the carousel example work too if the elements are 100 or more?

I looked into the proposed solution for pager and thought that an additional optional parameter that allows the creation of components before index 0 and after the last index (continuing with index 0) would also be an alternative for the carousel example in case the children exceed a specific amount.

[arkivanov]

The carousel example should work for any amount of components. You can enhance it and destroy components that are not needed, specifically for your use case.

The proposed pager API is finite. Though, I will think about making it circular. Thanks for the idea.

[malliaridis]

That's an important point I missed. So the main differences between the pager and the carousel would be the amount of children (finite/infinite) as well as the index available in the pager that is not present in the carousel?

[arkivanov]

Carousel is just an example of the Generic Navigation model. The proposed pager would also use Generic Navigation under the hood. This means that one can already create their own carousel and pager navigation, as well as many other kinds of navigation.

Currently, the idea with the pager API is to cover the specific use case of swipeable pages, with the ability to also preload side components. It's always possible to switch to Generic Navigation if something doesn't fit well.

[malliaridis]

Thanks for the clarification. I think I should try taking a more passive positioning in this topic. I feel like I am not aware of the main differences and benefits of the individual navigation models that are proposed. 😅

[marcguilera]

Master/detail or single child: Basically a non-nullable overlay, may be useful for bottom nav bars if the developer does not want to stack children.

[arkivanov]

I would suggest to just use Child Stack with only one child at a time, and just grab the active child in the UI. But let's gather more feedback on this.

[moffpage]

Hi! Could you provide more info on that?

[arkivanov]

Not sure who are you asking, but just in case my suggestion is to use Child Stack, and always replace the active child with another one using replaceAll function. In the UI, subscribe to Child Stack using subscribeAsState Composable function (or similar in other UI frameworks) and display the active child.

[pablichjenkov]

That is going to be really handy!
I'd like to see the BottomBar navigation pattern.

[pablichjenkov]

Right, each Navigator would come with a default UI that tries to cover the component standars(lets say material 3). That is what react-navigation does, take a look into this example https://react-navigation-example.netlify.app/
Perhaps an a configuration parameter could be provided to turn on off colors and such. If a developer wants to modify it, then they would have to create their own.
The module could have a DefaultDecomposeDrawer and if a developer wants something new they would need to create a DevXDecomposeDrawer Perhaps extending from the default. It would be a tradeoff, you write less code at the expense of using defaults.

[arkivanov]

How the implementation would know the amount of tabs, their titles and icons? Shouldn't it be also provided as some sort of configuration data class?

[pablichjenkov]

The way that library does it, for instance the TabNavigator(https://reactnavigation.org/docs/tab-based-navigation)

<NavigationContainer>
      <Tab.Navigator
        screenOptions={({ route }) => ({
          tabBarIcon: ({ focused, color, size }) => {
            let iconName;

            if (route.name === 'Home') {
              iconName = focused
                ? 'ios-information-circle'
                : 'ios-information-circle-outline';
            } else if (route.name === 'Settings') {
              iconName = focused ? 'ios-list' : 'ios-list-outline';
            }

            // You can return any component that you like here!
            return <Ionicons name={iconName} size={size} color={color} />;
          },
          tabBarActiveTintColor: 'tomato',
          tabBarInactiveTintColor: 'gray',
        })}
      >
        <Tab.Screen name="Home" component={HomeScreen} />
        <Tab.Screen name="Settings" component={SettingsScreen} />
      </Tab.Navigator>
    </NavigationContainer>

Notice the screenOption, is basically a Tab factory based on the route. Not sure how it best translate to decompose. Perhaps something like below:

BottomNavigator(
     tabFactory = { childComponent ->
           when(childComponent) {
                 is CountersChild -> Tab1()
                is MultiPaneChild -> Tab2()
                is DynamicFeaturesChild -> Tab3()
                is CustomNavigationChild -> Tab4()
            }
     }, 
     childrenComponents = rootComponent.children
) {
          when (val child = it.instance) {
                is CountersChild -> CountersContent(component = child.component, modifier = Modifier.fillMaxSize())
                is MultiPaneChild -> MultiPaneContent(component = child.component, modifier = Modifier.fillMaxSize())
                is DynamicFeaturesChild -> DynamicFeaturesContent(component = child.component, modifier = Modifier.fillMaxSize())
                is CustomNavigationChild -> CustomNavigationContent(component = child.component, modifier.fillMaxSize())
            }
}

[arkivanov]

Thanks for the clarification!

[malliaridis]

If I am getting it right this would mix UI components with navigation logic and make it harder to maintain over time, especially if Decompose focuses on multiplatform support. I think the current ChildStack covers this use-case well without direct dependencies to UI libraries. But what might be beneficial in regards to this idea would be to add simplified abstractions of ChildStack implementations for different scenarios, naming them accordingly.

Just for my understanding, would BottomNavigator in the example above need to be a Composable function if Compose would be used?

[pablichjenkov]

NavigationDrawer: Navigation drawer when the screen is small and left/right side panel when the screen is big.

[arkivanov]

Interesting! At the first glance, I would just try using Child Overlay. The UI could signal the screen type to the component, and the component would control whether the overlay is active or not. Just a rough idea. Let's gather more feedback.

[malliaridis]

The M3 NavigationDrawer has two different types, standard and modal. And on larger screens one might consider using a NavigationRail (additional UI component) for opening a NavigationDrawer of type modal on larger screens instead of a permanent side-panel / NavigationDrawer of type standard.

How would the different scenarios be taken into account in case Decompose would provide a NavigationDrawer?

[arkivanov]

A related discussion that might be useful: #430