A modern programming language that makes developers happier.

kotlinlang

:mega: The design for upcoming `StateFlow` is documented in a new issue. Your feedback is welcome: <https://github.com/Kotlin/kotlinx.coroutines/issues/1973>

Some of that is going over my head (since I don't use flow yet), and I'm just starting to move towards a UI architecture where my UI simply observes a UiState. I was thinking that Flow would have already been perfect for this. Why is StateFlow needed?
From what I can understand in the PR above, is it because the it's read only and has a concept of a last value i.e. state? context: rx/flow/observables beginner, but I do understand the concept behind just making my UI observer a state and it just reacts to it.

This is just one the implementations of the great `Flow`.

<@UN85K2RQR> Consider the situation where you have a UI elements bound to a flow (visually displaying the most recent update from that flow), but then you need to take those same values and make an API call with them. Something like a confirmation screen (“here’s the data you’ve entered, is it correct?“)

With a normal flow, you’d have to cache the most recent values in the UI class manually, so that you can pass those values to the API call when the user clicks “submit”. The StateFlow could eliminate that kind of boilerplate code, so you can just reach into the Flow itself to get the most recent values that should be submitted

Will it be possible to make FlowState  Android lifecycle aware? (custom dispatcher or something :thinking_face:)

`stateIn(lifecycleScope)` is the best we get I think.

^ I was just wondering that myself. This could be a much more flexible replacement for LiveData if it could be Lifecycle-aware

there is a `lifecycleScope` extension in androidx
and this scope has launchWhenXXX (XXX - is lifecycle state: created/started/resumed) funs. Block inside launch will be resumed after it's suspended *only* if it's in correct state

So
```lifecycleOwner.lifecycleScope.launchWhenStarted {
   flow.collect {
      // todo
   }
} ```
is lifecycle aware

<@UD17D4K8W> thanks for the example. I'm still not 100% sure I understand the difference, but its helping. I guess I'll have to use Flow to really understand why I would instead want a StateFlow

I guess I was thinking if I'm working on an Android project and I have my ViewModel and it exposes a single Flow&lt;MyUiState&gt; then I would still be able to emit MyUiState without any issues. In your example if I needed the users input, I would imagine the the UI would in turn tell my ViewModel that a value has updated, and then the Flow&lt;MyUiState&gt; would update and emit that new state.

Is this more or less similar to livedata on android?

<@U0B8UEMV1> This looks to me like it is a  reinvented State M-word, no? :slightly_smiling_face:

getting and setting should be suspend functions for that, it feels more like the subjects in Rx or livedata on android :smile:

Ah, right. Seems that now I'm seeing universal fp abstractions everywhere, dunno if it'll pass :wink: