In `Nav3` the mantra is “you own the backstack”. W...

# compose

[ursus]

In Nav3 the mantra is “you own the backstack”. What does that mean precisely? Is it only saying I can mutate it arbitrarily, or does it talk about the lifetime as well?

In other words, can I keep the instance anywhere I please (i.e keeping it inside a static singleton) or does it always effectively have to be scoped inside the setContent { … }?

[Jack Boswell]

Both - you create the instance wherever, and pass it around as you please. Even the type is flexible!

[ursus]

is it a good idea though to keep it outside the composition though? dont i lose all the saving restoring etc?

[Jack Boswell]

You don't get the utility function that handles that for you, but as long as you're managing that yourself it's fine

[ursus]

what would be the benefit of the non utility function way?

[ursus]

Okay, so others, what I was missing is that act of reading the state is what subscribes it for changes, not the act of creation the state

So it only matter what you pass into NavDisplay(backstack = backstack), that gets subscribed for changes

[piyush]

You are right, compose can still store whatever nav stack you want and observe changes to it. Using NavKey has some advantages on serialization. You can create your own back-stack using below use it.

val backStack = remember { mutableStateListOf<Any>() }

Or what I like is a wrapper eg. Navigator holding it and use that instead.