[FR Jetcaster]: Rethink empty, loading, success, and error states in

[arriolac]

Is there an existing issue for this?

• I have searched the existing issues

Is this a feature request for one of the samples?

• Yes, this is a specific request related to this samples repo.

Sample app

Jetcaster

Describe the problem

Jetcaster uses a sealed interface to display different states of the UI. For example:

sealed interface ScreenUiState {
    data object Loading : ScreenUiState

    data class Error(
        val errorMessage: String? = null
    ) : ScreenUiState

    data class Ready(
        /* Params here */
    ) : ScreenUiState
}

However, this may not be the best set up UX-wise as intermediate error states would result in the entire screen showing an error vs. showing an error as part of a partially rendered screen.

Describe the solution

A possible solution would be to fold loading and error states into a single screen state data class.

data class ScreenUiState(
    isLoading: Boolean,
    errorMessage: String?,
    /* Params here */
)

Other proposals are welcome.

Additional context

See discussion in #1363 (comment)

Code of Conduct

• I agree to follow this project's Code of Conduct

[yongsuk44]

I personally think that managing multiple distinct states within a single object can make Compose code less readable and harder to manage.

Hmm... If I think about it simply...
I believe that managing each state separately could allow for more versatile responses in various situations.

private val refreshing = MutableStateFlow(false)
private val _state = MutableStateFlow<ScreenUiState>()
private val _error = MutableStateFlow("")

combine (
    // ...
)
    .onStart { refreshing.value = true }
    .onEach { _state.value = it }
    .catch { throwable -> _error.value = throwable.message }
    .collect { refreshing.value = false }

what do you think..?

[arriolac]

I personally think that managing multiple distinct states within a single object can make Compose code less readable and harder to manage.

Yes, that was the impetus for using the sealed interface approach though that did create some limitations as per the description of this issue.

I could imagine a scenario where you might have multiple loading/error states on the same screen. In that case, I would prefer to use a Result in the screen state instead of having a separate flow for loading / errors. For Jetcaster, however, the solution you proposed could work since there aren't any screens where that scenario could apply.

[yongsuk44]

I could imagine a scenario where you might have multiple loading/error states on the same screen. In that case, I would prefer to use a Result in the screen state instead of having a separate flow for loading / errors.

Yes, I also think that using Result or sealed types is more efficient in typical scenarios

After reading the comment by mlykotom, I imagined a scenario where the Success UI is maintained while the Loading UI appears simultaneously. Based on this, I suggested this because I think it might be more efficient to manage the states separately. 🤔

Thank you.