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:
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?
(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))
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.
hey @paulbutcher . yes :normalize-db-fn is an option, so re-frisk becomes unusably slow. after upgrade or after changes in your app ?
oh ok i see , now you have cljs data in app-db, ok