re-frame 2021-02-19 | Slack Archive

az05:02:42

Is it bad practice to subscribe from inside a computation function in reg-sub? I’m trying to figure out how to materialize relationships but I don’t have the nested data until the computation function.

lsenjov06:02:43

You probably want reg-sub-raw then

henryw37410:02:00

@aramz maybe signal functions? https://github.com/day8/re-frame/blob/2965ffeda9b8f3b687e2c3e0ba9a62e7fe64c0bb/src/re_frame/core.cljc#L201

henryw37410:02:36

new blog post on re-frame and firebase: https://widdindustries.com/clojurescript-firebase-simple/ which talks about signal functions and limited use of re-frame app-db. feedback welcome 🙂

andre10:02:24

hi, in some cases i can see in traces that subscription run in each tick, even if there are no changes in app-db, why it might happen ? so it seems like subscription is broken and it just run on each tick

andre10:02:28

hm interesting if i hot reload and clear cache it won't be run anymore

andre10:02:29

ok it seems like subscription is used in event handler

andre10:02:49

and at some point its broken and started to run on each tick

p-himik10:02:58

It's not broken, it's just not cached.

andre11:02:59

but why is it run on each tick ?

p-himik11:02:23

I don't know what your code is exactly so I cannot answer that. Perhaps that event handler is called on each tick, perhaps something else.

p-himik11:02:17

Alternatively, you might be right and there might be some bug. But again, I can't say anything without having an MRE.

lassemaatta11:02:55

I also often need a snack before debugging a problem 😀

p-himik11:02:23

I already had breakfast. :)

p-himik11:02:56

Huh, it's been quite some time since I heard "MRE" used in a meal-related context.

andre11:02:58

yes sure, thanks

Clément Ronzon16:02:46

Hey Guys! Happy Fried-day! I was facing an conflict issue in my project and I'd like to have your input on the way I resolved it. # The problem In my project I had the tim-v interceptor registered globally:

(re-frame/reg-global-interceptor trim-v)

This is handy because it makes the event handlers registration less verbose. For instance:

(rf/reg-event-fx
 (fn [_ [prop]]
   {:dispatch {::some-event prop}}))

This was working perfectly until I had to use the cool re-pressed library. This library registers event handlers the way one would if trim-v wouldn't intercept the event. For instance:

(rf/reg-event-fx
 (fn [_ [_ event-type]]
   {::keyboard-event {:event-type event-type}}))

That's where the conflict happens, because of trim-v the event-type is actually passed as the first element in the second parameter of that handler and is consequently ignored. # My solution to that problem I wrote a custom reg-global-interceptor that checks if the namespace of the event is within a whitelist, in which case it will apply the interceptor, otherwise it won't.

(defonce ns-whitelist #{"foo" "bar"})

(defn- event-is-whitelisted
  "Returns true if the event is in the namespace white list"
  [whitelist context]
  (contains? whitelist (-> context
                           (get-coeffect :original-event)
                           first
                           namespace
                           (split #"[\./]")
                           first)))

(defn- get-whitelisted-int
  "Executes the interceptor only if the scope falls in the whitelist"
  [whitelist interceptor]
  (let [{:keys [id before after]} interceptor
        whitelisted (partial event-is-whitelisted whitelist)]
    (->interceptor
      :id id
      :before #(if (and (some? before) (whitelisted %)) (before %) %)
      :after #(if (and (some? after) (whitelisted %)) (after %) %))))

(defn- reg-global-interceptor
  "Delimits the scope of the interceptor"
  [interceptor]
  (re-frame/reg-global-interceptor (get-whitelisted-int ns-whitelist interceptor)))

# Some thoughts This adds a good amount of additional computing and I am not sure how to solve that problem in a more efficient way. Thanks in advance for your help please answer in a thread

p-himik16:02:37

In this code block:

(rf/reg-event-fx
 (fn [_ [_ event-type]]
   {::keyboard-event {:event-type event-type}}))

why not replace [_ event-type] with just [event-type]?

Clément Ronzon17:02:07

Because this code is from re-pressed which is an external project/dependency: https://github.com/gadfly361/re-pressed

p-himik17:02:15

I see. In general, I don't think that it's a good idea to use event-modifying interceptors globally. In my projects, I have a custom versions of reg-event-* functions that inject that interceptor automatically. kee-frame does it as well, for example.

Clément Ronzon17:02:09

Good point! This means that my problem is due to a bad pattern/design. Maybe it'd be good to mention exactly what you just wrote in re-frame's documentation about interceptors? :)

p-himik17:02:39

Perhaps - you can always open an issue an submit a PR. :)

Clément Ronzon17:02:48

But I would steal those lovely words from you 😄 I'll try, thank you @U2FRKM4TW!!

p-himik17:02:26

I consider all my community activities to be under the CC license. :) NP!

👍 3

2021-02-19

Channels