Fork me on GitHub
James Amberger01:05:48

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 have to reset subscription cache, it's documented.

🙂 1

You probably have that cache reset set up on hot reload, that's why it works with shadow-cljs.


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)?


I'd use 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


hmm, what if.... you wrap that in a reaction??


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)]
to this:
(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 deref-input-signals


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 deref-input-signals. but it's uncommon. I'd say just use reg-sub-raw. There are zero downsides.


but deref-input-signals is not recursive


(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.


aha! I think I see now


But heed my words about reg-sub-raw. :) In the end, using it will be shorter and much more clear than any amount of indirection you can invent.


there is a tradeoff though - reg-sub-raw cannot be cached


  (fn [input-sub args]
      (subscribe @(subscribe [input-sub args]))))
  (fn [output]
    ;; do something with the output
something like this?


I use 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 reg-sub.


> something like this? You need an extra @ in front of the outer subscribe.


oooh that's a great point about sub doing the caching


But just do this:

(rf/reg-sub-raw ::sub
  (fn [_db [_ input-sub args]]
    (subscribe @(subscribe [input-sub args]))))
Notice how much simpler and shorter it is. There's just 0 extra things.


and the subs cache is keyed by :` [_ input-sub args]` whatever is in there


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.


> and the subs cache is keyed by :` [_ input-sub args]` whatever is in there Yes.


haha yea, I agree with you, I'm trying to get the picture you have in your head in my head lol

🙂 1

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

👍 1

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

👍 1