responding to myself: it looks like i'm just going to have to bite the bullet and handle this like HTTP requests are handled. I was hoping that the async nature of this API could have been abstracted away from my re-frame code to keep it simple, but i don't see a way around it

@lgessler If you would write such code, your whole UI would block until the resource is delivered.

@lgessler definitely don't block in an interceptor. Definitely. Instead, you wait for the resource to become available (or error) and then dispatch that result The arrival of the resource (or an error associated with the request) is correctly modelled as a new event.

Anything new or novel which will cause the application's state to change or UIs to be updated, etc, is modelled as an event. So teh arrival of a resource is no different in nature from the user clicking a button. The event announces that something of interest happened and the event handler knows how to compute the implications (effects). So listen on that core.async channel for when the resource arrives and, when it does, dispatch a new event.

Perhaps look to this for inspiration (no sign of core.async but there is an async callback on success and failure): https://github.com/Day8/re-frame-http-fx

The lein re-frame template is using dependencies which are a little out of date.

Hi, are there any performance guidelines with updating reagent/re-frame ratoms? I found one of my event handlers takes about 3-5 seconds to change a big data structure in a large app-state, it is very slow.

@p-himik @mikethompson thank you both for your help 🙂 I'm really enjoying re-frame, btw.

@cmal can you give more information on what you're trying to achieve? I don't think there is anything re-frame or reagent specific to doing large amounts of data processing