hmm, is there a way to call an effect handler from an effect handler?

:dispatch / :dispatch-n fx

These are event handlers, not effect handlers.

@niklas.collin You can probably refactor the relevant code from the effect handler and call it from another effect handler.

Yeah, it's an indirect call which makes it a bit tricky. I feared this would be the case. Need to ponder on this a bit

Well, another solution would be to dispatch from your effect handler, and return an effect from the triggered event handler, but it's even worse.

The use case is OAuth2 refresh token usage when an earlier XHR fails due to expired token

So, XHR is done from an effect, it gets 403, this is passed to event handler which initiates the refresh token stuff, when that succeeds it tries to do the original XHR again

May need an additional event handler in between

If you come up with a working code and the code does not have sensitive license, perhaps you could post it here - someone may find it useful, and some people could try to improve your solution.

Like :refresh-token-succeeded or whatever which then triggers the effect

Unfortunately I can't publish this code

Hi!

was wondering whether anyone had some thoughts of how to cope with (a bit of) local state when dispatching events. e.g. dispatching an event that does some server update, and on success dispatches some other events (that part's fine) and also changes a tidbit of local state to, say, hide a modal, or leave edit mode, or similar

would it be even remotely sensible to have a "callback" effect coming out of some event?

@alex340 I just use :on-success and :on-failure parameters of :http-xhrio effect or something like that.

well, sure, but those expect to dispatch something

I'm talking about a bit of local state, not in the app-db

I'd say that if some state is needed to be changed as an effect of some server interaction, then this state is not that local, including just a flag for a modal dialog visibility.

not something I want to argue about - it's not pleasant to deal with purely local state in some global database. showing a dialog or not has nothing to do with the business logic of the app, it's purely representational within a given component. I could write the component in a number of ways such as showing some tab, or a dialog, or a confirmation box, or showing the whole thing in a modal that's supposed to close, etc

hence the hopefully to-the-point question as to whether "callback effects" is something that is reasonably sensible or not

not to mention you could any number of those dialogs, modals, tabs, etc, and I don't necessarily want to cope with unique-ifying those things in the database by prepending some arbitrary ID or similar

it's just not a sensible way of doing things 🙂

@alex340: I would have the component subscribe to some piece of data in your app-db that can be translated into the local state - similar to the logic used in http://blog.cognitect.com/blog/2017/8/14/restate-your-ui-creating-a-user-interface-with-re-frame-and-state-machines - My opinion is that if you want to pass local state around in a re-frame application then it may be a sign that your components need to be adjusted - there are some good resources available for that helped me get over this desire for different components I've wanted to build (the re-com library is a good source of ideas). If that doesn't work for you, it may be worth investigating alternatives to using re-frame that may fit your needs better - the tradeoffs in re-frame may just not suit your application requirements as well as something else.