What is best practise for multiple compose navgrap...

# compose

[0xf1f1]

What is best practise for multiple compose navgraphs in a single project ? I currently have 1 navgraph per set of behaviours i.e. Customer settings, customer add, customer delete will all be in its own navgraph, and add/delete/update bookings will all be in a separate navgraph. Is this good practise ? I have noticed that this messes with the startDestination because it doesn't like data classes, and needs a simply object. This is a problem becuase each screen will naturally need variables like IDs so it can load the correct data

[Stylianos Gakis]

What's the problem with start destinations having data, I'm pretty sure that should still work 👀

[0xf1f1]

that is no longer the case in 2.8.0 it seems - When setting startDestination=Booking where Booking is @serializer data class Booking(id: String) I get the following error: kotlinx.serialization.SerializationException: Serializer for class 'Booking' is not found. Please ensure that class is marked as '@Serializable' and that the serialization compiler plugin is applied.

[Stylianos Gakis]

Oh, well you need to pass something for the initial data too, wouldn't you? Otherwise what will id be?

[0xf1f1]

Not sure I follow

[0xf1f1]

In the case of 2.8, it is a blank object i.e. object Booking - very strange decision because as pointed out, passing data around is a key part of navigation. At the moment I just create an empty composite as a work around

[0xf1f1]

but this issue is what triggered the question

[Stylianos Gakis]

If you got a destination which needs an id: String to work. How could you say that your start destination is something without saying what that String will be?
If you just navigate to that navGraph, where would it go as a start destination?

[Ian Lake]

I mean, you do need to create an instance of the class if you want to use it as the destination: Booking is Companion object for a data class, not the class itself, while Booking("home") is an instance of Booking, which is a perfectly valid start destination

[Ian Lake]

But to answer your broader question, it makes sense to segment your graph into one or more nested graphs, sure, but you wouldn't be swapping them out for one another - they'd all be part of one large graph that includes everything (remember the graph is all possible destinations - like a physical map - just because it is on the map doesn't mean you'll always go to it - that's what your business logic is there to define)

[Ian Lake]

And generally, you'd navigate directly to the destination you want, you wouldn't rely on navigating to a graph just to pass that same fields to its start destination

[0xf1f1]

@Ian Lake Ah, so that is what was meant by companion object. Instantiating Booking in startDestination fixes the issue but I am a little stumped by it. Considering there is no way I will have access to the booking Id at that stage, I have to instantiate it with a blank value i.e. startDestination=Booking(id = "") - this of course doesn't feel right. Is it a good idea to put destinations that require variables as the startDestination ? What exactly should be put here, and what should one avoid ?