Hello everyone! Breaking the ice here with the first question, or more precisely asking for general ...

# orbit-mvi

[Carlos Muñoz]

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).

[Carlos Muñoz]

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?

[Mikolaj Leszczynski]

👋 I’ll try to respond as best I can

[Mikolaj Leszczynski]

@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.

[Carlos Muñoz]

Thanks for replying @Mikolaj Leszczynski!

If done with one flow without looping back, I found a limitation posting a side effect conditionally:

[Mikolaj Leszczynski]

I see, thanks for this. I think allowing you to return null in this case makes this more flexible

[Mikolaj Leszczynski]

@Carlos Muñoz I’ll see what we can do to make this more flexible 🙂

[Carlos Muñoz]

Or maybe just offering access to the side effect publisher? Not sure if it matches the detail exposure standards you guys have :)

[Carlos Muñoz]

Thinking about something like this, that also could help merging sideEffect and postSideEffect (just a suggestion)

[Mikolaj Leszczynski]

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…)

[Carlos Muñoz]

That's a great idea

[Mikolaj Leszczynski]

thanks a lot for your suggestions!

[Mikolaj Leszczynski]

expect a new version shortly 🙂

[Carlos Muñoz]

woohoo!

[Mikolaj Leszczynski]

I’ll try to get this out by this evening.

[Mikolaj Leszczynski]

We need to take stock and set some milestones first though. The API needs to stabilise rather soon 😅

[Mikolaj Leszczynski]

@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.

[Carlos Muñoz]

Just saw this. No worries, no rush! Let me know if I can collaborate somehow : )