Sealed state structures vs. navigation children

[sergejsha]

This is a call for discussion and opinion exchange.

While implementing screens with a sealed state structure like

sealed interface State {
    data object Loading : State
    data class Content(val userName: String, val userEmail: String) : State
}

I realized that the state holds a navigation aspect in it - Loading represents one child and Content another one. The difference to the conventional navigation is that the navigation path is represented by the state and is dispatched to view as a state.

An alternative to it would be to define two navigation children, one per a sealed sub-type, and declare a flat data class state for content.

@arkivanov Do you have any opinion or thoughts on this? Are there any best practices for such sealed states?

[arkivanov]

From my point of view, using sealed classes for states (e.g. the LCE pattern, aka Loading/Content/Error) totally makes sense. Usually Loading and Error states are pretty simple to be extracted as a separate components.

However, extracting Loading state to a separate component may be useful, e.g. in cases when the navigation graph depends on the data being loaded. An example of this could be a server-driven sign-in/sign-up flow, when the server tells the client which screens should be shown in which order, etc.

[YektaDev]

... An example of this could be a server-driven sign-in/sign-up flow, when the server tells the client which screens should be shown in which order, etc.

To add an experience in this regard, your example is exactly what I did and it couldn't be better. In that case, I had an Authentication component as the parent, which held the required subcomponents like SignUp, LogIn, Verification, etc.