when using sealed classes for the viewstate in android, how do you handle updating part of the viewstate? For example:

sealed class ViewState {
    object Idle : ViewState()
    data class Content(
        val headerText: String,
        val bodyText: String
    ) : ViewState()
    data class Error(
        val message: String
    ) : ViewState
}

How do I update just the title for example? I see a lot of examples use sealed classes but they dont seem so great in practice...

Write diffing code, code that can detect the differences between the current and new state and only updates the changes/diffs. This is not trivial and that is why folks often have more than one (partial) view-states being emitted by a view model, that then won't need this diffing code.

ya my previous approach was to have a separate stream for loading and error messages, but that seems not to be the approach most people take

There's an extension for LiveData called distinctUntilChanged() that you can use. This way, if you have a LiveData holding the viewstate and you update the LiveData in your VM (for example), then it will only emit the new viewState to your View layer if there was an actual change in the previous state to the new view state. This way you don't have to handle the diffing logic yourself

I'm not sure this answers the question. I'm not using livedata I'm using StateFlow. It already does the behavior you described but that doesn't answer the initial question

@Vincent Williams I think sealed classes are great, but using them for view states is a bit weird to me (and if anyone has a link explaining why they could be great, I'd love to read it). Basically you are mapping domain objects into partial view objects, only to map that within the View itself with extra logic (aka harder to test as it is in the view layer) to actual view properties. So that said, to get to your question: Perhaps you can use multiple view states. Like one for the mutable content (which can be Idle, Success, Error, perhaps Loading) and one for fixed content (like title). In that case you separately observe them and do a thing like

otherViewState.value = otherViewState.value.copy(title = newTitle)

Or you could give the original ViewState some abstract fields like title which all the other child have to implement:

sealed class ViewState {
	abstract val title: String
	data class Idle(override val title: String) : ViewState()
	data class Content(
		override val title: String,
		val bodyText: String,
		val headerText: String
	) : ViewState()
	data class Error(
		override val title: String,
		val message: String
	) : ViewState()
}

Which you can update as such:

viewState.value = when (val oldValue = viewState.value) {
		is ViewState.Idle -> oldValue.copy(title = newTitle)
		is ViewState.Content -> oldValue.copy(title = newTitle)
		is ViewState.Error -> oldValue.copy(title = newTitle)
	}

Or, what I would do, define 1 view state data class for your view that contains everything:

data class ViewState(
	val title: String,
	val bodyText: String,
	val headerText: String,
	val errorMessage: String?,
	val isErrorVisible: Boolean
)

which you simply update your stateflow by

viewState.value = viewState.value.copy(title = newTitle)

Basically I just have the state as a bunch of BehaviorSubject or MutableStateFlow, and then combine them to construct view states. Any manual changes in the view state come from emissions in upstream subjects, then sealed classes work really well

State as sealed classes is only good for views that have distinct states. For example a screen that shows either loading, or the results, or an error. When you want to model state that is not distinct try having one state class with stateful properties. This is a great article https://zsmb.co/thoughts-about-state-handling-on-android/

@George Theocharis Thanks for that article! That makes sense that some views would not take so well to sealed classes. Especially because error handling does not always result in an error "state". Sometimes its just something like a snackbar popup

Yes. Sometimes i model my state properties with sealed classes. As for navigation, it’s probably better to have a secondary stream like flow to send one time events also called effects.

for navigation, I have just been passing the navcontroller into the viewmodel constructor directly