Open arriolac opened 4 months ago
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..?
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.
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.
Is there an existing issue for this?
Is this a feature request for one of the samples?
Sample app
Jetcaster
Describe the problem
Jetcaster uses a sealed interface to display different states of the UI. For example:
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.
Other proposals are welcome.
Additional context
See discussion in https://github.com/android/compose-samples/pull/1363#discussion_r1581044482
Code of Conduct