@p-himik I’d recommend looking for this https://github.com/Day8/re-frame-async-flow-fx#advanced-use The :dispatch-fn allows for inspecting data of incoming event vectors.

It basically allows for regular callbacks using correlation-ids, so you know by which specific event next one was invoked.

you could see example here: https://gist.github.com/troglotit/fa52d56bf6add4dab400c251a056c1b4

here’s some discussion on the feature https://github.com/Day8/re-frame-async-flow-fx/pull/10

What does dynamic-vec refer to here? https://github.com/Day8/re-frame/blob/master/src/re_frame/subs.cljc#L255

to answer my question, it "exists for historical reasons and is borderline deprecated these days" (https://cljdoc.xyz/d/re-frame/re-frame/0.10.5/api/re-frame.subs#subscribe)

@troglotit Thanks for the links. Not sure I follow though. How would that work in the trivial example above with :start and :end with an xhr request in between?

Here’s example of business logic: I can pass args to my next “callback events” and I know that at last position there will be my payload.

The above snippet by itself is surely possible to implement without :async-flow and request-flow with about the same number of lines.

Hmm, yeah 🙂 but it enables true “event processing” with combining any amount of chain of async stuff without losing any context of which event had been produced.

But these chains will be ad-hoc in each and every case, and hence it's not different from composing them by yourself since each variation of :on-success of each effect already accepts arbitrary arguments and appends the result as the last argument. Well, at least in my case.