Another quick question: if you have a multistage intent, can you have multiple reduce calls intersp...

# orbit-mvi

[kenkyee]

Another quick question: if you have a multistage intent, can you have multiple reduce calls interspersed w/ network/db calls?
e.g.
reduce { state.copy(loading = true) }
val results = loadstuff.await()
reduce { state.copy(loading = false, data = results, loadingPhase2 = true) }
val results2 = loadmorestuff.await()
reduce { state.copy(loadingPhase2 = false, extradata = results2) }

[Mikolaj Leszczynski]

Yes, of course!

This is one of the advantages of using Orbit versus traditional redux style approaches - the entire business logic of the intent is in one place rather than spread out over several components.

[miqbaldc]

our actual usage to differentiate the each intent calls was to have a single responsibility in this case, so the method has its own intent block to test

[Mikolaj Leszczynski]

You are launching 3 intents here, so are running the risk of them executing in an undefined order if you have some longer-running operations in them - particularly switching context or launching sub-coroutines.

Another way to do this is to make the functions execute with the intent block as the receiver e.g.:

fun doSomething(...) = intent {
   validatingData()
   validatingResult()
   updatingState()
}

suspend fun SimpleSyntax<STATE, SIDE_EFFECT>.validatingData() {...}

That said, the potential race condition is highly situational so your mileage may vary. You might find you’re fine with the original solution

[miqbaldc]

one of our teams also suggest the workaround to use SimpleSyntax extensions approach in this case (@Anang Kur). Therefore it’s preferred than executing 3 different intent in former ways?

Even tho’ the SimpleSyntax extensions seems coupling our method to orbit-mvi framework in this case 🙏🏻

[Benoît]

You can (and should) abstract away SimpleSyntax. That's what we did, this way if we ever decide to move away from Orbit, or to use another framework for a single feature, our code is still re-usable

[Benoît]

Essentially we did this, which is closer to other MVI framework like Mobius

This way we are still framework agnostic