Fork me on GitHub
#re-frame
<
2019-09-25
>
mikethompson00:09:08

An global interceptor?

mikethompson00:09:36

See FAQ on how to set one up

danielneal07:09:30

cool, yep used a global interceptor thanks!!

mikethompson08:09:17

@danieleneal the other way you can do it, which is not quite as good IMO, but I'll include it for completeness is ...

mikethompson08:09:33

to create your own version of dispatch. Let's call it emit

mikethompson08:09:07

And then you make email log whereever it needs to about what event is being queued, before then actually calling dispatch

mikethompson08:09:02

The problem with this method can be (in some cases) that lots of events are dispatched in a hurry, and although you are log them all ... later on you are not sure which one you are currently processing. Generally speaking this method can work reasonably. You emit an event and then handle it. Then you emit another one, then handle it, etc. There's only ever one event at a time. BTW, the other problems with the emit approach is that you then have to use an effect handler :emit rather than :dispatch. Which means yo uhave to write that effect handler too.

mikethompson08:09:20

So, yeah, not as good. But mentioned for completeness

escherize15:09:45

Since we use re-frame we live in the future already, but here's a nice article I found about changing states. (also dips into api states, etc.) https://josephg.com/blog/api-for-changes/