what is the correct way to generate a list-list-de...

# compose

[Pablo]

what is the correct way to generate a list-list-detail ui? I mean... having first a list of categories, then, a list of places for that category, and finally a detail of the place. In therms of design, it is only a screen with just a viewmodel and 3 possible uis? or it is first a list screen with their own viewmodel, and then a list-detail screen with their own viewmodel?

[Pablo]

if I select the second option, I'm still thinking how to pass the argument of the selected category to the list-detail second screen, and I'm stuck with the navigation component, because as categories is a separated screen from the list-detail, they must be two different screens on the navigation menu, and that is non sense, because you can't enter the list-detail without being selected first a category

[Stylianos Gakis]

This can be modeled in both ways. You can have separate routes, with their own ViewModels.
You can also have it be one route with one VM and then handle showing or not showing the details screen separately. In fact if you want to support some sort of tablet UI which wants to show both at the same time then you need to have them be in the same route.

If you split it in two as you say what is the problem when you say “they must be two different screens on the navigation menu”, why is that so? If the details screen is a detail of some specific item on the first screen, you should only be navigating to it if you’ve clicked on of those items. And you can take that item’s ID to pass into the detail screen. From there, if you got the right ID it’s just a matter of fetching the information from your source of truth, wherever that may be.

[Pablo]

I don't mean that the list and the detail from the list-detail screen must be two routes/screens

[Pablo]

I mean that if the LIST of categories is the screen A and the LIST-DETAIL of places is the screen B... as categories list is a separated screen from the list-detail of places, they must be two different screens on the navigation menu, one for screen A (list of categories) and one for the list-detail screen B (list of places and detail of a place) and that is non sense, because you can't enter the list-detail of screen B without being selected first a category, so you can't have a route for screen B and a button for screen B in the navigation rail for example, because can't access it without a category selected

[Stylianos Gakis]

Why would you have a destination in the nav rail to a destination that does not make sense to go to without a parameter?
Just... don't put it on your nav rail perhaps?

[Pablo]

you mean having it on the navhost as a destination, but not on the navigation rail, isn't it?

[Stylianos Gakis]

Yeah of course. An app may have hundreds of different routes, but what goes in the nav rail/bottom nav is only some select few ones that make sense on their own

[Pablo]

and what is preferable? that? or having just one screen and one navigation destination with just a viewmodel and 3 possible uis for the LIST-LIST-DETAIL?

[Pablo]

this second option of just one screen seems to be more simple, as you don't need to pass parameters of selected category to the list-detail screen and it's viewmodel

[Pablo]

what option should be preferable or cleaner?

[Stylianos Gakis]

You can read this again https://kotlinlang.slack.com/archives/CJLTWPH7S/p1710710928557949?thread_ts=1710693442.850619&cid=CJLTWPH7S
It depends what you need.

I'd suggest make it work first as separate destinations since that's gonna be simpler. And after you're done and that works you can see if you want the other approach instead.

[Stylianos Gakis]

One screen if anything sounds more complicated, not less complicated. If you have a separate destination for the detail the only thing you need to pass to it is one ID nothing else. Then that screen can do everything it needs to do by itself since it knows the ID of that item.