-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FR Jetcaster]: Rethink empty, loading, success, and error states in #1376
Comments
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... 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..? |
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 |
Yes, I also think that using 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 #1363 (comment)
Code of Conduct
The text was updated successfully, but these errors were encountered: