A modern programming language that makes developers happier.

kotlinlang

image.png

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&lt;T&gt;` 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?

:wave: I’ll try to respond as best I can

<@U0B8C23EK>
Doing this the way you are with `.on&lt;Status.X&lt;Generic&gt;&gt;` is actually not well supported at the moment. The `Generic` type is erased at runtime so if you had `.on&lt;Status.Result&lt;Int&gt;&gt;` and `.on&lt;Status.Result&lt;String&gt;&gt;` 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.

Thanks for replying <@UPWE6PJCE>!

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

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

<@U0B8C23EK> I’ll see what we can do to make this more flexible :slightly_smiling_face:

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)

Yep <@U9D52BJF2> 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…)

expect a new version shortly :slightly_smiling_face:

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

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

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

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