Carlos Muñoz
11/04/2019, 11:00 AMStatus<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).Status.Failure
is instance of a specific type. Will you apply another transformation in that case?Mikolaj Leszczynski
11/04/2019, 12:11 PM.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
11/04/2019, 12:32 PMMikolaj Leszczynski
11/04/2019, 1:30 PMnull
in this case makes this more flexibleCarlos Muñoz
11/04/2019, 1:40 PMsideEffect
and postSideEffect
(just a suggestion)Mikolaj Leszczynski
11/04/2019, 1:46 PMpost(...)
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
11/04/2019, 1:51 PMMikolaj Leszczynski
11/04/2019, 1:51 PMCarlos Muñoz
11/04/2019, 1:52 PMMikolaj Leszczynski
11/04/2019, 1:53 PMCarlos Muñoz
11/06/2019, 3:37 PM