Open chpill opened 7 years ago
Okay, I think I was missing the point a bit. Only effects should be exposed with some dispatch functions, as they are the only ones that should be causing side-effects. So injecting the dispatch functions as coeffects is useless. The do-fx interceptor must provide effects handlers with those dispatch functions.
Note to self: the do-fx
interceptor only need to provide the regular dispatch
function:
As the effect handlers are going to be called during a "dispatching" ie when *handling*
is true (see here), they cannot use a synchronous dispatch.
This should be better with https://github.com/chpill/re-frankenstein/commit/c3e28389c840305f1a4686628e1a19c111e08689
I just realized that my comment about synchronous dispatch earlier was in fact mistaken. Many effects will in fact trigger asynchronous behaviors. In that case, it should be possible to do a dispatch-sync!
...
I started to try writing an effect handler, akin to https://github.com/Day8/re-frame-http-fx
In the code of the handler, there is a call to
dispatch
that is made...So we need a way to allow effect handlers to dispatch "locally". The best solution is probably to inject partially applied
dispatch!
anddispatch-sync!
as coeffects.Currently, all the swapping out of handlers and middleware happpens before the creation of the
frank
, so we cannot add this coeffect at that moment...I see 2 solutions here:
frank
, systematically add an interceptor at the beginning of the chain that will make suredispatch!
anddispatch-sync!
are available as coeffects. The issue with this is that what is stored in the registry will no longer be completely representative of what happens when you dispatch...frank
hold a registry atom instead of a registry value. Then change the state of that reference to add the new coeffect. Maybe the "local version" of thedo-fx
interceptor that we inject can be extended with a:before
that takes care of that.I'll have a go at solution 2