Is there a way to have an effect call another effect?

No, but here is all the code involved: https://github.com/Day8/re-frame/blob/master/src/re_frame/fx.cljc#L34-L38

As you can see, you could do whatever you wanted quite easily.

By that, I mean you could: 1. create your own reg-event-XXX 2. which inserts your own interceptor which handles effects in whatever way you want

Sorry, just to clarify, I need to have the fx-handler function return a map with the additional effects I want and I need to recursively call fx/do-fx?

At the moment, there is an interceptor called do-fx. It is the one whose :after actions whatever is in :effects. When it does this actioning, it loops over the keys of :effects and calls the registered handler for each supplying only the value for that key as a parameter (see code link provided above)

As a result, there is currently no scope for adding further/new effects during the processing of an existing one

However ...

that's just the current arrangement and there is plenty of scope for pulling together your own version of these lego blocks

Crazy idea #1: you insert your own interceptor which looks at the :effects and adds further to it

(reg-event-fx
     :some-id 
    [my-effects-interceptor]          ;; <---- do initial processing of effects here
    (fn  [cofx  v]  {} ))

That way the :after fn of my-effects-interceptor gets to process the :effects before the standard do-fx gets to them

Anyway, kinda depends on what you are trying to do .... is this related to datascript ?

not really. I’m trying to convert my app from the old way of doing things (everything was a db-handler) to this new effectful way and I’m running into problems. Before it was fairly easy to chain together a series of dispatch handlers (A —> B —> C), but if move them into effects then I can no longer call the next effect.

does that make sense?

Hmm. Not entirely.

I would have thought that anything previously possible would still be possible.

But this is all a bit abstract

Can you frame the problem with a specific example?

So, I guess I'm saying that nothing really changes. If you were chaining A->B->C ... you can still do exactly that ... but you don't call dispatch within an event handler any more, you have an :dispatch effect. But otherwise the same overall process.

I gotta head off

Right. I’d love to do that, but I still haven’t wrapped my mind around Crazy idea #1. I’ll take a look at it tomorrow when my brain is fresh. Thanks for the feedback.

@seantempesta: You can also register a new effect :B and add that to your output map - then your effect handler A will have 2 effects - whatever it did before, plus the effect B - if you have some old style code you could post that might help, there is more than one way to decompose things and what makes sense will depend on your situation. There's also multiple dispatch with a built in handler if that works better.

Thanks. But B depends on A and C needs both A and and B to run in my case, so they need to run sequentially. And I don't care about intermediate states. Either I get to C or a failure occurs along the way and I bail out.

Well that was rather abstract. Here's the actual use case. I need to startup several pieces of code (datascript and lunr.js as an example) and have them restore their state from local storage (if it's possible). I'm using react native, so LocalStorage is asynchronous. So I need to start LocalStorage, retrieve the data from storage for lunr.js, if that succeeds, retrieve the data for datascript, then link them together so future updates to datascript will update the search index.

@seantempesta: interceptors, I think!

@andre: looks very cool. I'll check that out.

Yeah. I just need to sit down and figure out how to use them. :)

Sounds like a fun project at least :) Let us know if you run into trouble figuring ot how to use interceptors, they should be pretty straightforward but it took me a while to really wrap my head around them.

@seantempesta is this on startup of the app ?

Sounds like it. In which case, it sounds like you need re-frame-async-flow