Carlos Muñoz11/04/2019, 11:00 AM
class to be used as the output of any transformation (basically the result type of our use case executions). It can take the values
. - 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 (
doesn't have side effects,
posts a side effect,
has both internal and view related side effects).
is instance of a specific type. Will you apply another transformation in that case?
Mikolaj Leszczynski11/04/2019, 12:11 PM
is actually not well supported at the moment. The
type is erased at runtime so if you had
they would both trigger (possibly causing an exception in the one with the wrong generic). Generally you should avoid using generics in
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ñoz11/04/2019, 12:32 PM
Mikolaj Leszczynski11/04/2019, 1:30 PM
in this case makes this more flexible
Carlos Muñoz11/04/2019, 1:40 PM
(just a suggestion)
Mikolaj Leszczynski11/04/2019, 1:46 PM
method to the receiver instead to not expose RxJava within the DSL (we are going to try to support coroutines flow eventually…)
Carlos Muñoz11/04/2019, 1:51 PM
Mikolaj Leszczynski11/04/2019, 1:51 PM
Carlos Muñoz11/04/2019, 1:52 PM
Mikolaj Leszczynski11/04/2019, 1:53 PM
Carlos Muñoz11/06/2019, 3:37 PM