I want to have something like that sealed class ProfileViewState object Loading : ProfileViewState() object Error : ProfileViewState() data class ProfileLoaded( val name: String, val email: String ) : ProfileViewState()

For

Loading

and

Error

, looks like it is recommended to be defined as

Effect

instead of

State

Can you give a source @miqbaldc? Can’t remember giving that advice 😉

afaik, the

Loading

&

Error

considered as one-off events(?) cmiiw, but yes, I’m also forgot where, is it orbit-mvi or others references 😄

I would treat them as states, personally - but I don’t know what your use case is.

found it here: https://github.com/pedroql/mvflow/issues/30#issuecomment-799411710 if using states for

Loading

or

Error

we have to modify/mutate our previous state (to allow calling

Loading

or

Error

again) but, if the OP didn’t have the similar usecase/situtaion, using states for

Loading

or

Error

was a good pick

Right, now I have the context. Pedro’s answer in the link is spot on. State is not meant for repeatable, one off events. In terms of LCE (Loading-Content-Error) these states are not repeatable (e.g. you don’t need to invoke loading twice in a row) and mutually exclusive - it makes sense to make then part of the state.

Nice, thanks for the insight! Agreed with you, for LCE,

State

is preferred a modal dialog or navigation (e.g: start an activity), should be use

State

, instead of

Effect

? cmiiw

Modal dialog -> State (unless you don’t care about e.g. losing the dialog on rotation) Navigation -> Always

effect

, otherwise you get a sticky navigation - every time you subscribe to the view model again (e.g. coming back to the screen) would instantly trigger navigation

(e.g. coming back to the screen)

ooops, agreed, forgot the above use cases 🤣. thanks again K 🙏

This discussion has answered my question, thank you very much