Hi <@U0234N0QYSK> we were trying to use multiple D...
# compose-destinations
a
Hi @Rafael Costa we were trying to use multiple DestinationNavHost for similar kind of scenario as mention in this issue: https://github.com/raamcosta/compose-destinations/issues/492
r
You can still have multiple NavHosts
The graphs passed to them need to be “NavHostGraph”. That’s the only change on v2
Basically, these graphs cannot have a parent
Which on v1 would be ignored anyway. So nothing really changed, we just enforce a correct graph structure in this case
a
Ok so if I create graph structure like this: MainGraph • LoginGraph(External Module) • HomeGraph(External Module) MainGraph loaded in DestinationNavHost then, in Home Module: If I define another DestinationNavHost with TabGraph which will be there in :navigation module, so that it can be used for tabs screen. Then everything should work?
r
Not sure I understood the home module part. Is that related to HomeGraph? If you’re passing TabGraph directly to the DestinationsNavHost on home module, then it cannot have parent graphs - needs to be defined as such with @NavHostGraph annotation
s
This graph looks simple enough that you don't even really need multiple NavHosts though right? Couldn't it all be in one NavHost, with your feature modules just contributing their own subgraph to that one NavHost?
a
Correct TabGraph will be NavHostGraph and HomeGraph will just contain DestinationNavHost as a content of BottomBar
@Stylianos Gakis There are more graphs to the main graph and we want to avoid having conditional check to hide/show bottom nav bar, so we can actually have direct screens declared in Home module by checking current state of bottom bar but if we have DestinationNavHost in Home module then it will be easier.
r
It looks ok. And there’s no reason it would t work if the setup is correct. Let me know if you find any obstacles.
👍 1