Hello everyone Breaking the ice here with the first question

Question

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

Carlos Muñoz · Answer

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 · Answer

wave I ll try to respond as best I can

Mikolaj Leszczynski · Answer

< Carlos Muñoz> 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

Carlos Muñoz · Answer

Thanks for replying < Mikolaj Leszczynski> If done with one flow without looping back I found a limitation posting a side effect conditionally

Mikolaj Leszczynski · Answer

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

Mikolaj Leszczynski · Answer

< Carlos Muñoz> I ll see what we can do to make this more flexible slightly smiling face

Carlos Muñoz · Answer

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 · Answer

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

Mikolaj Leszczynski · Answer

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 · Answer

That s a great idea

Mikolaj Leszczynski · Answer

thanks a lot for your suggestions

Mikolaj Leszczynski · Answer

expect a new version shortly slightly smiling face

Carlos Muñoz · Answer

woohoo

Mikolaj Leszczynski · Answer

I ll try to get this out by this evening

Mikolaj Leszczynski · Answer

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

Mikolaj Leszczynski · Answer

< 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 · Answer

Just saw this No worries no rush Let me know if I can collaborate somehow