re-frame

https://github.com/Day8/re-frame/blob/master/docs/README.md https://github.com/Day8/re-frame/blob/master/docs/External-Resources.md
Rob Knight 2021-05-15T12:32:29.475600Z

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-himik 2021-05-15T12:38:09.475700Z

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.

1👍
andre 2021-05-15T17:47:43.476Z

hey @paulbutcher . yes :normalize-db-fn is an option, so re-frisk becomes unusably slow. after upgrade or after changes in your app ?

andre 2021-05-15T17:51:34.476200Z

oh ok i see , now you have cljs data in app-db, ok