Hello and happy new year! :slightly_smiling_face: ...
# orbit-mvi
g
Hello and happy new year! šŸ™‚ If i need to synchronise this calls:
Copy code
containerHost.intent {
        reduce { state.copy(...) }
        reduce { state.copy(...) }
    }
}
is there any way I can assure that the second reduce happens after the first one? Use case: I’m doing an ā€œundoā€ swipe to dismiss. The
androidx.compose.material.SwipeToDismiss
removes/hides the item from the UI (
LazyColumn
) before removing it from the UIState. Therefore we need to simulate that removal from the UIState by emitting a new one without the item, and then, we emit a new state again with the item back in the list. My question appears because I can only succeed if I do something like:
Copy code
fun undoDelete(id: Long) {
    containerHost.intent {       
         val last = state.clients.toList()
         reduce { state.copy(clients = state.clients.filterNot { it.id == id }.toList()) }
         delay(50)
         reduce { state.copy(clients = last) }
    }
}
but it feels like šŸ”Ø šŸ˜…
m
I'm not sure I follow... šŸ¤” Generally if you reduce like the above it should be in sequence, as it all runs within the same coroutine. Is this a case of state updates happening so quickly they get conflated by the
StateFlow
?
PS for UI-bound intents ideally you should use
blockingIntent
g
maybe, because the delay does the trick
m
i.e. if you don't do any background work at all
g
I’l try
m
yeah try
blockingIntent
, if it doesn't help then it's likely the conflation that's the problem
I'm not sure we can do anything about it other than what you already did
g
btw, how can I have access to
blockingIntent
?
containerHost.blockingIntent
?
can’t find it šŸ¤”
m
Are you on the latest build?
g
Copy code
orbitMviCore = "4.4.0"
gonna check it if there’s a new one šŸ™‚
is it 4.5.0 ?
(yes it is ^^)
the problem is with the conflation i guess,
blockingIntent
by itself didn’t solved
m
Unless you can change your logic then, I think the delay is acceptable..