@joelsanchez That's an FAQ almost https://github.com/Day8/re-frame/blob/master/docs/SubscriptionsCleanup.md#a-final-faq But a few have disagreed with my stance. You amongst them, from the looks :-)

understood the reasoning for why you oppose to it, don't think it's hurting me the way I have structured my db

good to know it's not total heresy at least

@lgessler I don't think there is a fixed practice on this. The question to answer for yourself is: "what structure can I use so that my (forgetful) future self will know (instantly) where to find the various "parts" of your widget".

Hi all, I have a question about “nested” subscriptions as I’m trying to subscribe on top of a subscription that needs a parameter. Is it possible to pass parameters to reg-sub signal functions? If so, could you please show me how? Thanks in advance!

@cperrone

(rf/reg-sub
 :nested-sub
 ;; Signal fn
 (fn [[_ x] _]
   (rf/subscribe [:inner-sub x]))
 (fn [inner-sub [_ x]]
   (do-things inner-sub)))

I believe

I can’t recall if it is bad practice to just deref the subs from within a rf/reg-sub, but in rf/reg-sub-raw I think it is normal enough - so as an alternative, I think you can ditch the higher-level form of rf/reg-sub for these cases if that is helpful

(rf/reg-sub-raw
 :nested-sub
 (fn [db [_ x]]
   (r/reaction
    (let [inner @(rf/subscribe [:inner-sub x])]
      (do-something inner)))))

ok great, thank you. I had tried the syntactic sugar style before, but it didn’t like it. I’ll give it a go tomorrow morning (pretty late here in ireland :D).

Yeah, the syntactic sugar way doesn’t support it

my db takes a list of items, so I pretty much need to pass item ids all the time.

(I’m probably 90% sure on that without double checking recent releases)

I ended up doing a (gasp) macro for the more complex sub case like this. I just had too many with this sort of boilerplate and it was getting error prone to write it. (I’d miss place the queryvec args or forget some etc.) I’m not typically one to advocate one-off macros though, so I won’t say do it. Just saying if you have a lot, you may encounter some of the same annoyance that I found.

i’m currently playing with specter and created a bunch of clean composable navigators for my db. But the subs would probably mimic a lot of the work that the navigators do and I could take advantage of the re-frame caching.

Yeah, I like the caching aspect

In the 2 apps I’ve done with re-frame so far, I got quite a bit of use out of subs relying on other subs.

yeah, it’s an awesome feature 🙂

ok, gotta go, but thank you so much!! Good night!

good night!

yay! Thanks @mikerod. I just tried it. The first form you gave me works great 🙂. Have a great Sunday! (you certainly made my day today!)

I'm trying to use re-frame on a React Native app and the "re-frame overwriting event handler..." console warnings are really inconvenient (they need to be dismissed manually or cover half the screen). I've tried creating a teardown fn that would remove all existing event handlers every time I hot reload my app, but it both doesn't remove the warnings, and completely breaks the app b/c the event handlers are seemingly removed after my init sets them up again. Anyone know a better approach or workaround?

(My previous workaround was to memoize my init fn so it only ran once per session, but this had the serious limitation that then I couldn't get any event handlers or subscriptions to ever reload -- OK while I was doing purely UI layout, but not when wiring up app state handling and data flow)

Thank you @caleb.macdonaldblack

@pandeiro I think chrome lets you filter on your console logs. So you could do that and still be able to have other re-frame debug logs

@cperrone Yea unfortunately there is not way to pass query params into input signals using the syntactic sugar style

hey all, I'm writing an interceptor that uses an async API. the API returns the requested resource by putting it in a core.async channel. if this were the JVM, I'd use <!! to block my interceptor's execution until the resource has been delivered, but cljs's implementation of core.async doesn't include <!!. the next option normally would be to use a go block, but I need to guarantee that my interceptor will block until the resource has been delivered. does anyone have advice?