re-frame 2021-05-15 | Slack Archive

Rob Knight12:05:29

In all of the re-frame docs, signal functions for subscriptions look very simple. If I have a layer-3 "materialised view", it might have a signal function which takes some parameters to pass to lower-level extractors, and the results are processed in the computation function. However, I've started doing something like this:

(re-frame/reg-sub
  :foo
  (fn [[_ id]]
    (let [linked-entity @(re-frame/subscribe [:extractor id])]
      (re-frame/subscribe [:other-extractor (:field linked-entity)])))
  
  (fn [entity]
    ;; do something))

The crucial bit is the dereferencing in the signal function. I can't see an obvious reason for why this is bad, but I can't find any examples of anyone else doing this. Similar things are often done using reg-sub-raw though, so perhaps there's a reason for doing it that way instead? Has anyone encountered this kind of pattern before?

p-himik12:05:09

It's not bad from the perspective of how subs are implemented. I don't think it's bad per se, and I do that myself. You might want to use reg-sub-raw in such cases, but often deref'ing in a signal function is both simpler and easier.

👍 2

2021-05-15

Channels