Why not produce State from the Jetpack Compose, instead of Flow or StateFlow?

[dev-gvs]

Hi!

Why build a StateFlow or Flow stream, but not the Jetpack Compose State? Maybe I don't understand something, or I don't see a particular use case 🤔

P.S. Thanks to everyone who works on this library!

[JakeWharton]

We don't really use Compose UI yet, so State is a somewhat useless type to us. Our returned StateFlow is collected by our presenter-render integration layer which passes the models to the renderer which are almost entirely views. Additionally, StateFlow is a type which represents both a synchronously-available value as well as a mechanism by which you can subscribe to updates. With State you only get the former and have to use snapshotFlow for the latter. Except because of Google's failure to ship Compose in a true multiplatform context we cannot pass around State to multiplatform code whereas StateFlow is fully multiplatform.

Supporting State is as trivial as our StateFlow support which is built on a stream-type agnostic core function, and I'm not opposed to adding it. But like Flow, which I also consider a subpar experience for Molecule composable functions (since it has no ability to expose the synchronous value), I think State's uses are more limited in practice.

[dev-gvs]

Oh, now it makes sense. Thank you, Jake!

[DSteve595]

I personally expect that in practice, Compose UI (or, some Compose-based UI toolkit) will be an extremely common consumer for this library. With those, the State reactivity problem goes away.
I can see a State<T> not being that valuable given all it saves for Compose UI consumers is a collectAsState() call. To me it just feels like a "purity" thing; if Compose has its own API for "read me imperatively and you'll also get reactive updates", it would be nice to just use that, rather than taking a detour through StateFlow<T>.