In the context of for example what's discussed in <https://medium.com/bumble-tech/crash-course-on-th...

# decompose

[John O'Reilly]

In the context of for example what's discussed in https://medium.com/bumble-tech/crash-course-on-the-android-ui-layer-part-2-2335171467e0, is it fair to (among other things) describe a Decompose component as an "(observable) UI State Holder"? A big part of Decompose is also the shared navigation logic.....should we think of this as a separate distinct part of Decompose or should it be seen as being inextricably part of the components as well (e.g. could there be scenario where you'd use Decompose for state holder etc functionality but something else for navigation?)

[Arkadii Ivanov]

I usually say that a Decompose component is an encapsulating lifecycle-aware boundary between UI and non-UI code.

[John O'Reilly]

I'm preparing a talk at the moment and part of what I want to do is compare Decompose to other solutions and just not exactly clear how functionality corresponds. If we take KMM-ViewModel for example, clearly Decompose provides a lot more than it does but "shared observable ui state holder "for example seems a core part of both?

[John O'Reilly]

navigation then seems like another distinct area

[John O'Reilly]

some overlaps also then re. lifecycle awareness.....but perhaps still some differences (compared to say various "view model" implementations)

[Arkadii Ivanov]

The classic ViewModel has two mandatory responsibilities - to survive config changes and to stay alive while in the back stack. It can also optionally expose the state and accept UI events. Navigation is not possible at the ViewModel level.

The Decompose component has only one mandatory responsibility - stay on the back stack (or in general in navigation). The rest is optional, including navigation.

[John O'Reilly]

thanks, that's a helpful way of thinking about it

[Arkadii Ivanov]

Keep in mind that Stack is just one of the possible nav models. 😀