Hi Daniel, yeah, at the moment I am subscribing to a map which 'row'
then keys into.
On a related note, I am actually moving this sort of logic out into a
subscriber so the component is really quite dumb and gets
{:location-desc s/Str} rather than {:location-id ..}. It simplifies
the components quite nicely and is a nice separation of concerns (data
generation compared to rendering).
Thanks again for replying.
On 21 May 2015 at 10:48, Daniel Kersten <dkers...@gmail.com> wrote:
> It is my understanding that your second code snippet leaks memory. I think I
> remember Mike saying that you cannot safely create a reaction (which
> subscribe does) in render.
>
> Your first snippet looks OK to me as long as results doesn't change for the
> duration of the component.
> I guess the only ways I can think of making this work if results is dynamic
> is that location/render returns a map of all data and you key into it during
> render. Or the parent retrieves the data for each row rather than just id
> and passes it to row (and row is a dumb component).
>
>
> On Thu, 21 May 2015 09:24 Colin Yates <colin.ya...@gmail.com> wrote:
>>
>> Hi,
>>
>> I have a use-case where the component is given an id and it uses a generic
>> 'reference-data' (e.g. :location/render) subscription to render. Is it
>> possible and idiomatic to do something like:
>>
>> (register-sub
>> :location/render
>> (fn [db [id]] ....))
>>
>> (defn row
>> [{:keys [location-id]}]
>> (let [location-desc (subscribe [:location/render location-id])
>> (fn [state]
>> [:tr [:td @location-desc]]))
>>
>> (defn rows [results]
>> [:tbody
>> (doseq [r results]
>> [row r])])
>>
>> My understanding is that it isn't as 'row' is a form-2 component and the
>> data passed to the 'row' form is scoped to the constructor whereas the
>> 'state' passed to the fn returned by 'row' is per-invocation.
>>
>> In which case I do:
>>
>> (defn row
>> [{:keys [location-id]}]
>> (let [location-desc (subscribe [:location/render location-id])
>> [:tr [:td @location-desc]])
>>
>> Which feels wrong, but it might be fine.
>>
>> Clarity please :).
>>
>> --
>> 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.
--
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.
