@shader can you provide more details pls. I'm not following your question.

@mikethompson thanks for your response. I guess my problem is regarding code locality, in our current setup since all the side effects are expressed as middlewares for a given event, you can see everything that happens as part of the event. Once you start breaking it down to effects (and coeffects), the code will be spread among: reg-event-fx multiple reg-fx functions. Also, it is true that there are common side effects (dispatching, ajax calls, local storage, analytics), many times you'll have things that are conditional (dispatching only in certain states or/and params combinations, so from our experience it's easier to see all that in one place. Maybe it's easier to explain with example, I'll try to see if I can extract something from our code and show how it's currently done vs. the recommended way to do it with version 0.8+

@talgiat interceptors are just middleware - via a different name and mechanism. So whatever structure you currently have can certainly continue on. No need to change anything unless you want to (other than the code fiddles moving from middleware to interceptors). You no doubt know that, but just making sure that is clear. If your middleware previously did effectful things, then you can choose to also do effectful things in your interceptors too. On the other hand, you can now also choose to do those effectful things via :effects (from within your interceptors). Now, I'm guessing you already knew all this. But just making sure. I'm guessing you are wanting to understand how BEST to do it in the new world. Your concern in this regard is code locality.

Answering my own question, in addition to the async-flow-fx what @talgiat mentioned, it seems there is a built-in :dispatch effect handler that could be leveraged. I might start there.

(Referring to https://github.com/Day8/re-frame/blob/master/docs/Effects.md#dispatch)

@pandeiro this might be what you are looking for? https://github.com/Day8/re-frame-http-fx

It provides for an on-success and on-failure dispatches

Thanks @mikethompson -- I'm using that indeed, with the handlers

What I was asking about is specifically in the case of needing to chain together multiple ajax requests

And I've decided to go with, for now, the simplest solution of registering on-success handlers that return an additional :dispatch

(which then triggers the next ajax call)

In that case, probably async-flow-fx

as has been suggested

Yep, I looked at it and went a little cross eyed -- once my own code starts to do that to me, I will revisit 😉

Thanks very much for the input though, much appreciated