I'm currently porting an application from Jetpack Navigation to Decompose. I'm stuck on trying to pa...

# compose-desktop

[Sean Proctor]

I'm currently porting an application from Jetpack Navigation to Decompose. I'm stuck on trying to pass a value from a child screen to the parent screen. With Jetpack Navigation I could observe some LiveData associated with the backstack entry and pass data to the parent backstack from the child. I would like to do this in a way that the parent and child are not coupled. Does anyone have a suggestion? My first thought was to maintain the state in the root component, but I don't see how to do that in a way that only the parent can observe it.

[Arkadii Ivanov]

If I understood the question correctly, you should be able to just pass a callback to the child screen.

[Sean Proctor]

Maybe there's something that I'm missing. I have the child built from a Parcelable class, so I don't see how to pass a callback.

[Arkadii Ivanov]

Parcelable configurations are just child descriptors (or keys), they only hold minimal information required to create a child. This information is persisted on Android, e.g. on configuration change, process death, etc. But the main thing is that you manually create a child given a configuration, in the router(childfactory = { ... } function. This is the place where you can supply absolutely any dependency - a database, a network client, or a callback. Take a look at the examples.

[Sean Proctor]

Thanks. Looking into it.

[Sean Proctor]

I don't see how to get the callback from ScreenA without coupling ScreenB to ScreenA. My thought is to add a map to the root component and pass a key to ScreenB

[Arkadii Ivanov]

You pass a callback from a parent to a child. The parent is only aware of its immediate children. Children are not aware of the parent.

[Sean Proctor]

I guess I need to restructure my components. I said parent/child, but I guess they're more like siblings.

[Arkadii Ivanov]

Alright. So you need to send data between siblings. In this case there are two ways. 1. Create a PublishSubject (or a SharedFlow) in the parent, pass it to one sibling which will push data to it. And also pass it to another child which will subscribe to it. 2. Pass a callback to one child, when data is received - locate another child and call its method and pass data there. You can perform data transformation (mapping) in the parent level to avoid coupling.

[Sean Proctor]

Thanks! My tentative solution is to use a MutableStateFlow with a Map and key. The map and key to allow multiple concurrent listeners. One component adds data to the map, the other removes it.

[Sean Proctor]

Now I'm thinking it might better to make the receiver implement a certain interface and from the sender pop the router, and call the receive method of the activeChild if it implements that interface

[Sean Proctor]

Thanks for your help and for the library. Would it be interesting to have a sample using ViewModels? I'd be willing to write one if so. It might help me make a bit more sense of what I'm doing here also.

[Arkadii Ivanov]

It's not clear why you want StateFlow instead of SharedFlow? The former is conflated, the latter isn't. So if you send multiple values sequentially, the receiver may miss some of them. And what is the purpose of the Map and the key?

[Sean Proctor]

Google recommends using state instead of streams. I'm not clever enough to handle edge cases. https://developer.android.com/topic/architecture/ui-layer/events It's in the note at the end.

[Sean Proctor]

In my case, there are never multiple values because it's a return value from one screen to another. If there were, it could be handled by creating a list and removing elements as they're handled.

[Arkadii Ivanov]

I believe that note is for exposing UI events from a ViewModel and consuming them in the UI. It should indeed be performed via state. But communication between two ViewModels (or Decompose components) is more natural via streams of one-time events (or just normal callbacks).

[Sean Proctor]

The map/key is to handle the situation where two screens on the stack process events. For instance: Screen C is the one returning a value. Screens A and B can navigate to Screen C, so they both observe the return state. If they are both on the stack observing the return state, there needs to be a way to differentiate which screen should handle the state. Using a map and key seemed the most obvious for this.

[Arkadii Ivanov]

If that's a return value, then you can just add onFinished: (Data) -> Unit to one component. Then in the root supply this callback. When called, pop the screen from the stack, and call the another component's method with the result.

[Sean Proctor]

Ok, I'm going to create a simple example with that method.

[Sean Proctor]

I think this turned out pretty well. It's a pretty close approximate to what I'm trying to do. https://github.com/sproctor/decompose-example

[Sean Proctor]

https://github.com/sproctor/decompose-example/blob/54ddb995fe40378cbf4d3f434ea9b83c7eb0772d/src/jvmMain/kotlin/ui/navigation/RootComponent.kt#L63

[Arkadii Ivanov]

Yep! This should work. Just keep in mind that there is one corner case when the navigation might be performed asynchronously - when the Router is called recursively. So it is safer to use the onComplete callback - router.pop { <the rest of the logic> }. More information can be found in the [docs](https://arkivanov.github.io/Decompose/router/navigation/#the-navigation-process).

[Sean Proctor]

Ah, thanks!

[Sean Proctor]

If you want another sample, feel free to use that