This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aleph (1)
- # announcements (9)
- # aws (6)
- # babashka (18)
- # babashka-sci-dev (25)
- # beginners (79)
- # calva (30)
- # cider (34)
- # clj-kondo (25)
- # cljsrn (6)
- # clojure (26)
- # clojure-australia (1)
- # clojure-europe (6)
- # clojure-norway (1)
- # clojure-poland (6)
- # clojure-uk (3)
- # clojured (2)
- # clojurescript (14)
- # datomic (19)
- # events (1)
- # google-cloud (1)
- # gratitude (2)
- # helix (1)
- # hyperfiddle (2)
- # interceptors (1)
- # jobs (17)
- # joyride (96)
- # leiningen (5)
- # lsp (20)
- # minecraft (2)
- # nbb (5)
- # other-languages (1)
- # re-frame (34)
- # releases (2)
- # shadow-cljs (15)
- # spacemacs (1)
- # xtdb (19)
Seems evaluating a reg-sub in the repl doesn’t change the registered subscription’s behavior—I have to write out the file and let shadow-cljs watch do its thing. Is this expected?
You probably have that cache reset set up on hot reload, that's why it works with shadow-cljs.
More info you may find useful located here 👉 https://github.com/day8/re-frame/blob/master/docs/FAQs/Why-Clear-Sub-Cache.md
you can just trigger a render yourself in the REPL, just like the hot-reload would do
If I have subscription vectors stored in app-db and I want to use those in another subscription, am I forced to use
reg-sub-raw for this pattern? (or the equivalent of that - a layer2 sub with a deref in the compute fn)?
reg-sub-raw or a separate plain function that itself derefs one sub, feeds its value to the second sub, and derefs it as well. Of course, you'd use such plain function only in a reactive context.
that makes sense. I think ideally there'd be some way to deref signals in the input-signal-fn itself, but those derefs will not be captured because they happen outside of a reaction https://github.com/day8/re-frame/blob/69cf39552715fa410e7007b7fcbc894097d8db1f/src/re_frame/subs.cljc#L217
Yep. You can still use
reg-sub and even call
subscribe from the associated handler function. But it's worse than
reg-sub-raw because it will create an extra reaction with basically an
identity for a body.
oh sorry - I meant change the re-frame implementation:
(let [subscription (computation-fn (deref-input-signals subscriptions query-id) query-vec)]
(let [subscription (computation-fn (deref-input-signals @subscriptions query-id) query-vec)]
(and for backward compat you can say
(cond-> subscriptions (reaction? subscriptions) deref)
I'm not following. That
@ is already there - in
deref-input-signals. Unless your signal subscriptions return a reaction on their own?..
yea i'm thinking you'd have another layer of reactions/indirection
the idea is the inputs-fn optionally is itself a reaction -> it's return value is then passed to
trying to solve the "I want to use a subscription's output as input to subscribe in the inputs-fn"
You can already do that - exactly because its result is passed to
but it's uncommon.
I'd say just use
reg-sub-raw. There are zero downsides.
(deref? signals) (f signals) will return what the reaction returns, but not deref those values
I still don't follow why it would need to be recursive. You'd just
@ right within the reaction body - the reaction that you would then return from the signal function.
But heed my words about
In the end, using it will be shorter and much more clear than any amount of indirection you can invent.
something like this?
(rf/reg-sub (fn [input-sub args] (reaction (subscribe @(subscribe [input-sub args])))) (fn [output] ;; do something with the output ))
reg-sub-raw whenever I have to do something that signal functions can't handle on the surface, anything that goes even a tiny bit beyond obvious. Because I've "been there done that" - anything else is not worth it IMO.
> reg-sub-raw cannot be cached
...why not? It's
subscribe that caches things, not
But just do this:
Notice how much simpler and shorter it is. There's just 0 extra things.
(rf/reg-sub-raw ::sub (fn [_db [_ input-sub args]] (subscribe @(subscribe [input-sub args]))))
The only downside of
reg-sub-raw is that it doesn't have the same amount of tracing as
reg-sub has. But personally, I've never had any problems with it.
haha yea, I agree with you, I'm trying to get the picture you have in your head in my head lol
ok this is great, It's making more sense now - thanks for the assistance! I'll be playing with it some more to make sure I understand
as always RTFM - I have read this page many times, but "When the student is ready, the teacher will appear" ....
this is the line:
> In some cases, the returned
reaction might not even use
app-db and, instead, it might only use
subscribe to provide input signals. In that case, the registered subscription would belong to "Layer 3" of the signal graph (discussed in earlier tutorials).
having a firm understanding of reagent is key I'm realizing. Something I'm gaining more understanding of now