In `Nav3` I want to scope a instance to group of n...

# compose

[ursus]

In Nav3 I want to scope a instance to group of navkeys, and I need a explicit removal callback once last of the group was removed

class SandboxScopeDecorator(
    private val backStack: List<NavKey>,
    private val onSandboxRemoved: () -> Unit,
) : NavEntryDecorator<NavKey>(
    onPop = { poppedKey ->
        if (backStack.none { key -> key is SandboxKey }) {
            onSandboxRemoved()
        }
    },
)

How does this look? Is it a good idea to pass in the backstack into decorator? Or does this belong somewhere else?

[efemoney]

Nothing stopping you but personally I wouldn’t do this.

[efemoney]

I went a different route by using a component to manage “grouped entry keys”.

Basically I grouped my entries by a key then used the nav decorator framework to manage the whole thing such that once a “grouped key” comes into the backstack the associated object is created and once the last entry with that grouped key is popped, the group key (and its associated objetct) is removed.

In a scenario where I have the stack

A1 B1 A2 A3 C1 B2

There will be group keys A, B & C and A will only be removed when all the A entries are popped off the stack

[ursus]

I dont follow, you say a different route but sounds exactly like the snippet, i.e. you examine backstack in decorator for presence/lack of group keys, no? How does it then differ?

[efemoney]

Slightly different route then. The difference is going through the entire backstack on each pop operation.

[efemoney]

No I am NOT examining the back stack

[ursus]

so how? youre counting on concrete B2 key getting popped to signal the flow is over?

[efemoney]

Keep original nav key in metadata

[ursus]

but whats the call back you use, onPop? if so how do you know its the last one

I think I'm missing something

[ursus]

I can imagine if key == A1 then begin else if key == B2 then complete but I fear this is too brittle over time. Is this what you do?

[efemoney]

Screenshot 2026-05-02 at 10.38.59 AM.png

[ursus]

yes this I get but I'm talking about the maybeClear

[ursus]

could you please show that? or maybe just talk aboit it, does it keep some latch count internally and know when to actually clear?

[efemoney]

image.png

[ursus]

I see, a better latch count

neat, thanks!

[ursus]

btw entry.groupKey() is a extension inputting metadata right?

[efemoney]

Sort of … its the first lambda in the helper function.
In my case, yes, it sometimes grabs the key from the metadata and uses it to compute something.

Also a little bit of context: I didnt start with the helper function so yours doesnt need to look like it. I started with something resembling it but then I needed the same thing over & over so I extrat=cted this commom function.

[ursus]

im gonna test it out now but im little suspicious about the decorate/onPop ordering, are there any guarantees? say I dont push a new group screen but replaceTop .. isnt there a space for the group to get cleared and immediately started again?

(i.e. for the previous screen to get popped first and new one then decorated)

[efemoney]

The onPop is handled by nav3 so if it doesn't work determinately then that's a bug and should be reported

[ursus]

what I'm saying if is there a ordering guarantee, because I'm not sure there is, and this relies on ordering, or rather for decorate and onPop to overlap a bit

[efemoney]

Yes sorry I wasnt clear: My point is that the ordering is guaranteed by the framework. Its not something application code should care about. If it doesnt work as nav3 describes then its a bug.

What does nav3 promise? That decorate will be composed as long as that entry is in composition AND that onPop will be called when the specific contentKey is completely removed from the backstack. Simple.
Its with the guarantee above that I base my solution.

[ursus]

@efemoney So I'm playing with this approach, seems to work nicely as a callback, but if I want the cached value to be a DI component/graph instance representing the flow & the flow's accumulated data is not persisted to disc - it needs to be rememberSaveable somehow.

With the nested navdisplay approach I had I simply had a central place where to create the graph instance, and above it kept the saved state and then synced them in SideEffect (so the saved value always has the latest in memory state, so it can pass it into the factory of the graph come process restore time)

But now, since this new decorator approach is global - where would you keep track of the in memory state to save?