This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # arachne (108)
- # beginners (16)
- # boot (48)
- # cider (34)
- # cljs-dev (12)
- # clojure (237)
- # clojure-spec (50)
- # clojure-uk (5)
- # clojurescript (8)
- # cursive (1)
- # datascript (2)
- # datomic (6)
- # defnpodcast (1)
- # emacs (1)
- # fulcro (7)
- # hoplon (1)
- # keyboards (1)
- # off-topic (22)
- # re-frame (26)
- # reagent (2)
- # specter (16)
- # unrepl (6)
- # yada (1)
@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
@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!
(rf/reg-sub :nested-sub ;; Signal fn (fn [[_ x] _] (rf/subscribe [:inner-sub x])) (fn [inner-sub [_ x]] (do-things inner-sub)))
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
Just to show you other forms. I have reserved using
(rf/reg-sub-raw :nested-sub (fn [db [_ x]] (r/reaction (let [inner @(rf/subscribe [:inner-sub x])] (do-something inner)))))
reg-sub-rawfor cases where I need to use “inner” subscriptions that take arguments that rely on the results from other subscriptions though. (that may be confusing and you can ignore)
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).
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.
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.
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)
@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?