Fork me on GitHub
#re-frame
<
2022-08-22
>
fabrao17:08:49

hello all, I have one interceptor that I want not turn on in production, is there any way to do that?

p-himik21:08:29

Wrap registering such an interceptor in (when re-frame.interop/debug-enabled? ...). Of course, :require that namespace explicitly.

fabrao21:08:26

thank you again

fabrao21:08:02

I used this

(when (= js/goog.DEBUG true)
  (rf/reg-global-interceptor schema-check-interceptor))

p-himik21:08:31

(= ... true) is superfluous. But also, I'd use re-frame.interop still, because it marks that boolean in a special way. Maybe it's not necessary nowadays though, I haven't checked.

James Amberger20:08:37

Re-frame conceptual question! I have an event that creates an entity and an event handler that persists the entity to the backend. I have another event that “modifies” the entity and persists that to the backend. I want to allow user to do these in one click. I can make a third event handler that dispatches both events, but how do I ensure that the side effects happen in order, i.e. that my INSERT from no. 1 is finished in time for the UPDATE from no. 2?

p-himik21:08:07

Prefer function composition to event composition. If you can't do it directly, then extract relevant functionality from event handlers and compose the resulting functions. But if you must issue two separate requests for insert and update, just issue the update event as the :on-success event handler of the insert event.

James Amberger21:08:38

I’m in the your-second-paragraph case. So the :on-success event handler would have to update the db with the returned id of the new entity, and declare the update effect

p-himik21:08:01

> would have to update the db with the returned id of the new entity Sounds reasonable. > declare the update effect Not sure what you mean by "declare". If you mean just returning the effect and its arguments from the event handler, then yes.

James Amberger00:08:36

Yes, I’ll do as you say. Thanks @U2FRKM4TW.

👍 1