For Compose in an RxJava codebase, is there any re...

# compose

[kenkyee]

For Compose in an RxJava codebase, is there any reason to use LiveData? I know with regular databinding, LiveData works better in handling lifecycles, but was wondering if Compose like LiveData better than BehaviorSubjects? (we already know Compose likes coroutine stateflows better...just not ready to go full coroutines yet)...

[gildor]

I know with regular databinding, LiveData works better in handling lifecycles

What do you mean? Wat is better in bindings and livedata? Bindings do not support rxjava or even Flow (only state flow) so you cannot really compare them

[gildor]

I doubt that it's something different for compose when work with LiveData vs RxJava adapter, it has own composition lifecycle anyway, not activity/fragment one, so I don't see any real reason to use LiveData

[kenkyee]

Wat is better in bindings and livedata?

Livedata comment was from this longish blog: https://bladecoder.medium.com/kotlins-flow-in-viewmodels-it-s-complicated-556b472e281a

[kenkyee]

TLDR: LiveData works a lot better if you need full lifecycle support....
Makes sense that this doesn't apply to compose though so BehaviorSubject it is 🙂

[gildor]

I partially disagree with article, and imo LiveData problems do not worth having it side by side with Rx, but my comment was specifically about data bindings

[Adam Powell]

Compose's first-class observability support is for snapshots; Rx, LiveData and Flow are all peers in that all three are implemented as adapters that write into snapshot state when they emit new values. There's no significant reason to prefer any one of the three over the others, but there are reasons to prefer working with snapshot state directly if you have hot observable state rather than cold data sources.

[kenkyee]

You mean working with remembered snapshot substate? Trying to think of an example of what you described.

Thanks for confirming rx vs livedata isn't as critical as it is with the older layout stuff 🙂

[Adam Powell]

I mean working with mutableStateOf, mutableState[List|Map]Of , etc. Those are all backed by snapshots

[kenkyee]

That definitely makes sense... Those feel very much like useState in React. They're mostly used for internal state in composables/components.

[Adam Powell]

Snapshots are a general-purpose observable MVCC system. Compose is built with snapshots as a dependency, snapshots have no dependencies on anything else about Compose. You can use snapshots as part of any other code outside of composables. Composables will often combine remember {} and mutableStateOf to create something similar-ish to useState, but remember and mutableStateOf are orthogonal tools.