Do you at lest see the println statement having an effect?

Yes

it does print the correct value

and if I do

(let [orig-event (get-in context [:coeffects :original-event 0])
                   new-context
                   (assoc-in
                    context
                    [:effects some-path]
                    orig-event)]
               (println "BEFORE" (:effects new-context))
               new-context)

yet the arguments of the dispatched event are not correct

on the receiving hand

To add clarity to my intent: I have event-a that dispatches event-b, the interceptor should add to the arguments of event-b (a hashmap) the orig-event value, it's correctly done, but event-b doesn't see the orig-event value

To make sure it's not an XY problem - what exactly are you trying to achieve? And why are you doing it this way and not the more direct way where you put that info there explicitly?

It's currently done explicitely, but there are many possible event-a_1 , event-a_2 , that all dispatch event-b (this one is unique), and in some cases, event-b needs to dispatch again the correct event-a_...

So right now, when dispatching event-b I have a key :orig-event event-a_1 as part of the argument map of the dispatch, but I'm trying to create an interceptor that does that itself, to avoid having to type :orig-event every time and risking typos and such

I see. I would still pass that data by hand, I think. Even if it's 10 events doing that - :orig-event is just a keyword and you can't safeguard every keyword, and the event ID is already there as a value.

And in the case of an interceptor you're exchanging correctly typing :orig-event for remembering to having to provide the right interceptor. :)

Ok but that's not my question though 😅 I'm already doing that.

Oh, wait - that interceptor is in the event B handler.

Ah, I'm wrong, sorry. So yeah, you'll have to provide that interceptor to all the events.

But how do you dispatch B from A*?

it's a graphql request, so essentially we have event-a_1 -> graphql-request-event (with :http-xhrio) -> graphql-on-success-event and depending on the return value of graphql (e.g. pagination), we want to trigger event-a_1 again the way our a* events dispatch it is just with returning {:graphql-request-event request-args} instead of a {:dispatch [...]} and I just realised this seems to prevent the interceptors from triggering

something is shady on our side, I'll go back to investigate, thanks for the help !

And there are many ways to have a built-in effect dispatch an event: :dispatch, :dispatch-n, :dispatch-later, and their 3 combinations with :fx. And some libraries or your own code can add more - just like with that GraphQL key.

Not sure what you mean by "run" here. If it's building that you're talking about, I would recommend shadow-cljs.

My preferred way is with shadow-cljs. It has very good https://shadow-cljs.github.io/docs/UsersGuide.html: basically define your target depending on what you are looking to do, it supports multiple REPL options (nREPL, socket, others). Let us know what you are after!

yes.. I ment building of course... not the running part. And thank you for pointing out shadow-cljs 🙏