https://kotlinlang.org logo
#orbit-mvi
Title
# orbit-mvi
c

Carlos Muñoz

11/04/2019, 11:00 AM
Hello everyone! Breaking the ice here with the first question, or more precisely asking for general feedback about how do you usually organize action transformations, and if do you consider scalable an approach like the one below: - Have a
Status<T>
class to be used as the output of any transformation (basically the result type of our use case executions). It can take the values
Status.Failure(e: Throwable
,
Status.Loading
, and
Status.Result(payload: T)
. - Listen to any possible resulting status of a given type and reduce them all together. - If necessary, listen to specific result statuses separately. In the case shown below, side effects are different (
Status.Loading
doesn't have side effects,
Status.Result
posts a side effect,
Status.Failure
has both internal and view related side effects).
And, on a more tricky scenario, let's say we want to post a side effect only if the error in
Status.Failure
is instance of a specific type. Will you apply another transformation in that case?
m

Mikolaj Leszczynski

11/04/2019, 12:11 PM
👋 I’ll try to respond as best I can
@Carlos Muñoz Doing this the way you are with
.on<Status.X<Generic>>
is actually not well supported at the moment. The
Generic
type is erased at runtime so if you had
.on<Status.Result<Int>>
and
.on<Status.Result<String>>
they would both trigger (possibly causing an exception in the one with the wrong generic). Generally you should avoid using generics in
on
until we figure out if it’s even possible to support that. You can work around that by wrapping the generic class when looping back and listening to that instead. In this case though, why not have this logic as one flow, eliminating the need for a loopback? The side effects can check for the specific instances themselves. I know this may not be ideal (you’d expect the above to work!) but should be easier to follow I think.
c

Carlos Muñoz

11/04/2019, 12:32 PM
Thanks for replying @Mikolaj Leszczynski! If done with one flow without looping back, I found a limitation posting a side effect conditionally:
m

Mikolaj Leszczynski

11/04/2019, 1:30 PM
I see, thanks for this. I think allowing you to return
null
in this case makes this more flexible
@Carlos Muñoz I’ll see what we can do to make this more flexible 🙂
c

Carlos Muñoz

11/04/2019, 1:40 PM
Or maybe just offering access to the side effect publisher? Not sure if it matches the detail exposure standards you guys have :)
Thinking about something like this, that also could help merging
sideEffect
and
postSideEffect
(just a suggestion)
m

Mikolaj Leszczynski

11/04/2019, 1:46 PM
Yep @appmattus suggested something similar, we could add a
post(...)
method to the receiver instead to not expose RxJava within the DSL (we are going to try to support coroutines flow eventually…)
c

Carlos Muñoz

11/04/2019, 1:51 PM
That's a great idea
m

Mikolaj Leszczynski

11/04/2019, 1:51 PM
thanks a lot for your suggestions!
expect a new version shortly 🙂
c

Carlos Muñoz

11/04/2019, 1:52 PM
woohoo!
m

Mikolaj Leszczynski

11/04/2019, 1:53 PM
I’ll try to get this out by this evening.
💥 2
We need to take stock and set some milestones first though. The API needs to stabilise rather soon 😅
@Carlos Muñoz I think we’re going to take a bit longer, we’re working on a breaking DSL overhaul that will massively simplify maintenance. I will squeeze this change in there.
c

Carlos Muñoz

11/06/2019, 3:37 PM
Just saw this. No worries, no rush! Let me know if I can collaborate somehow : )
6 Views