I want to have something like that sealed class ProfileViewState object Loading : ProfileViewState...

# orbit-mvi

[Eric Ampire [MOD]]

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()

[miqbaldc]

For Loading and Error, looks like it is recommended to be defined as Effect instead of State

[Mikolaj Leszczynski]

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

[Mikolaj Leszczynski]

@Eric Ampire [MOD] you can use this sort of state without any issues - can you elaborate what problems you are facing?

[miqbaldc]

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

[Mikolaj Leszczynski]

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

[miqbaldc]

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

[Mikolaj Leszczynski]

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.

[Mikolaj Leszczynski]

Unless e.g. you wanted to display errors as one-off toasts that dismiss with time - then sure - use an effect

[Mikolaj Leszczynski]

best way to think about it is that if the components on the screen need to stick around forever or until some sort of action is taken then their state should be part of MVI state.

If they don’t stick around, like toasts or timed snackbars use an effect

[Mikolaj Leszczynski]

a modal dialog is a great example - a lot of people use an effect for this, but I disagree with that approach

[miqbaldc]

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

[Mikolaj Leszczynski]

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

[miqbaldc]

(e.g. coming back to the screen)

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

[Eric Ampire [MOD]]

This discussion has answered my question, thank you very much