You have to reset subscription cache, it's documented.

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

Thanks men

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 https://github.com/day8/re-frame/blob/69cf39552715fa410e7007b7fcbc894097d8db1f/src/re_frame/subs.cljc#L217

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

(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

(rf/reg-sub 
  (fn [input-sub args]
    (reaction 
      (subscribe @(subscribe [input-sub args]))))
  (fn [output]
    ;; do something with the output
    ))

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

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

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" .... https://day8.github.io/re-frame/flow-mechanics/#reg-sub-raw 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