Thanks Mike. Yeah, it is that ‘untidiness’ that happens when each subscription is per row for example that made me question it…
> On 9 Jun 2015, at 11:52, Mike Thompson <m.l.thompson...@gmail.com> wrote: > > On Tuesday, June 9, 2015 at 8:44:02 PM UTC+10, Colin Yates wrote: >> I understand that you can provide parameters when subscribing to something, >> but I am unsure when it is idiomatic to do so. The example in the >> documentation is for a static value (the number of results), but what about >> if those parameters change frequently. >> >> For example, let's say I have a subscription which renders a hierarchy. Each >> node in that hierarchy may be archived? s/Bool. When I want to render that >> hierarchy I need to ensure that I can see all non-archived nodes _and_ the >> node that I have currently selected regardless of whether it is archived. >> >> I could achieve this with something like: >> >> (register-sub >> :some-reference-data/hierarchy >> (fn [db [_ current-id]] >> (let [tree (load-hierarchy-with-node current-id)] (reaction tree)))) >> >> This means I will have many invocations of the above (subscribe >> [:some-reference-data/hierarchy my-id]) for many different ids. >> >> On the other hand, I could have a single subscription for the whole >> hierarchy and prune the tree outside the subscription. >> >> Which is more idiomatic? > > > > Both ways seem reasonable. Other forces will encourage one over the other. > > >> >> On a related note, in a component, is it OK to do [:div (do-something-with >> @(subscribe [:some-reference-data/hierarchy (:id node))) or is a memory leak >> waiting to happen? >> > > AFAIK, there's no memory leak here. BUT ... subscriptions should be in the > setup part of Form-2 components (outside the renderer). Otherwise you'll be > asking for a new subscription each time you render (which seem very untidy). > > -- > Mike > > > > > -- > Note that posts from new members are moderated - please be patient with your > first post. > --- > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojurescript+unsubscr...@googlegroups.com. > To post to this group, send email to clojurescript@googlegroups.com. > Visit this group at http://groups.google.com/group/clojurescript. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.
