Fork me on GitHub
#re-frame
<
2019-06-27
>
mikerod01:06:14

@mx06409 there is also re frame async flow lib for something like you describe.

eckardjf17:06:34

Thanks, this looks very promising (and useful for other scenarios I'm encountering).

👍 4
p-himik08:06:11

Hey. I noticed there's some work going on on re-frame-http-fx-2. I wonder - what made you decide to switch to namespaced keywords?

tomaas10:06:21

hi, a before interceptor has to return a updated contexted maybe as tutorial mentions. however i'd like my interceptor executed some validation and sometimes dispatch something else (canceling the actual handler).

p-himik11:06:35

You need to signal something to not execute the handler body. The default re-frame machinery cannot do this. You can either write your own versions of reg-event-* that execute the handler conditionally, or write some macro/function that would wrap your handler in a check for some flag that was set in a before interceptor.

tomaas11:06:39

@p-himik If i put (reframe/dispatch..) in my interceptor, the handler does not execute anymore.

tomaas11:06:27

it does what i want but I dont understand why the handler does not execute in that case etc.

tomaas11:06:10

wrapping every handler of all the events with the same logic is something i wanted to avoid with interceptor

p-himik11:06:13

Well, it will stop processing if you are not returning ctx from your interceptor because you're dropping the whole interceptor queue.

p-himik11:06:25

In general, you don't want to directly call dispatch from your interceptors - you want to add an effect that does something (add :dispatch if it doesn't exist or alter :dispatch-n. Or maybe something else)

p-himik11:06:06

You could write an interceptor that tinkers with the queue and removes the last :before interceptor since that's the one that actually executes the event handler if you use re-frame's standard reg-event-* functions. But I'm on the fence about this solution - it's not clear to me how internal the interceptor queue is, and it's rather easy to break something if you stray from the most common path.

mikethompson11:06:35

@p-himik the proposed new effect is keyed :http

mikethompson11:06:00

but, you are right, some of the effect keys are :http/xxxx

mikethompson11:06:30

It is still under development Might get to alpha about the end of next week We'll be taking comments at that point Still in a bit of flux

p-himik11:06:45

@mikethompson Thanks! It just really offends my eye to see so many namespaced keywords in one place, so I wanted to ask right away. Just in case - people developing Ring have also been thinking about pros and cons on namespaces: https://groups.google.com/forum/#!topic/ring-clojure/JfGrJS22XAc

oskarkv18:06:56

I'm using CIDER and figwheel-main. If I have this code

(rf/reg-event-db
 :initialize
 (fn [_ _] 1))

(rf/reg-event-db
 :update-db
 (fn [_ [_ value]]
   value))

(rf/reg-sub
 :val
 (fn [db _]
   db))

(defn view
  []
  [:div @(rf/subscribe [:val])])

(defn run []
  (rf/dispatch-sync [:initialize])
  (reag/render [view] (js/document.getElementById "app")))
And start out with doing (run) and (rf/dispatch [:update-db 2]) I see 1 and then 2 as expected. But if I then change my subscription to
(rf/reg-sub
 :val
 (fn [db _]
   (inc db)))
i.e. I added inc around db and reevaluate the code, re-frame: overwriting :sub handler for: ... name: "val" is printed in the browser console. But if I then do (rf/dispatch [:update-db 3]) I expect to see 4 in the browser, but I don't, I see 3. I need to refresh the browser for it to work. But refreshing the browser is kind of annoying. Why doesn't it work without? re-frame even says "overwriting :sub handler".

oskarkv18:06:45

ah, thanks