uniflow-kt
uniflow-kt copied to clipboard
Proposal for consistent handling of states & events with Jetpack Compose
Do you think something like this would be helpful for people using Jetpack Compose? The idea is to make things simpler and more consistent with the rest of the framework.
Basically it's a copy of LiveDataObserver.kt with @Composable in it's API. I am new to those things, so please check if the code is correct, especially the event part. Feel free to adjust it as you see fit. This is just a proposal. I am not insisting on anything.
Due to the new dependency you might also want to put this into a separate module. On the other hand, I would assume that "uniflow-android" is also fine for just one class. Mid-term most people will use Jetpack Compose and have this dependency anyways.
Hello @StephanSchuster
yes for Compose, we would try to separate build to isolate needed API.
I don't understand well why you need to rewrap existing APIs with @composable 🤔 The current API are already working with Compose - https://github.com/uniflow-kt/compose-samples/tree/uniflow/Jetsurvey
Hi @arnaudgiuliani,
I am not saying that wrapping is needed. It is not.
But I think it would provide the following benefits:
- It's shorter, easier and nicer to write
onStates(viewModel) { state ->
instead ofviewModel.states.observeAsState().value?.let { state ->
. -
onStates(viewModel) { state ->
is more consistent withonEvents(viewModel) { event ->
thanviewModel.states.observeAsState().value?.let { state ->
. - The code would look exactly the same for Jetpack Compose and the Android UI Toolkit:
onStates/Events(vm) -> ...
- You can provide helpful debug logs like you do in the non-compose world (
UniFlowLogger.debug("onStates/Events - ...
)
In your Jetsurvey example, you are using onEvents()
only for navigating. I think if you want to show a Compose Snackbar or the like on incoming events, you would need the @Composable API as shown in the PR, right?
Ok, let me see that.
Any plans to publish on this?
let me get back on this project yes 👍