I hadn't considered the fact that you're passing the full cursor in. Seems okay
to me then. Daniel makes a good point about the possibility of the cursor path
changing.
I guess as an alternative you could pass in a channel to the component, and
communicate the search back up to the parent, who would make the web service
call. That would preclude having any logic in the child.
Lucas
> On 4 Dec 2014, at 22:25, Colin Yates <colin.ya...@gmail.com> wrote:
>
> Thanks both.
>
> 'data' in the callback in opts is the cursor. It is invoked in response to
> data in the component changing (e.g. the component is displaying filter
> criteria, when that is changed the search should be re-run). It derefs and
> reads the cursor and causes an (asynchronous) request to the back end.
>
> At some point in the future the response will turn up and then the response
> is processed. The processing of the response makes use of reference cursors,
> and doesn't reference 'data' at all.
>
> However, my understanding is that because it is a cursor it is safe to passed
> along like this, hence the need to deref it when reading from it?
>
> Would you pass these callbacks in as props or local state then?
>
>> On Thursday, 4 December 2014 14:11:51 UTC, Daniel Kersten wrote:
>> Ok, just checked Om source - build does in fact rely on the component it is
>> built in, so passing a built component into another component to be rendered
>> there is definitely not a safe thing to do!
>>
>>
>> Render uses (binding [...] ...) to capture details such as the components
>> state, instrumentation, parent etc which is then accessed during calls to
>> build.
>>
>>
>> On 4 December 2014 at 14:05, Daniel Kersten <dker...@gmail.com> wrote:
>> Ah I just looked at the code: the past issues with multimethods were when
>> you use one directly as an om component, but you are using it to call build,
>> so your problem is unrelated after all.
>>
>> It does sound like a bad idea to build components and then pass them around
>> rather than passing the component function although I don't know the details
>> of why this doesn't work.
>>
>> As for change-fn, it works as long as the cursor path doesn't ever change
>> since you're then not actually relying on changes to the closed over value,
>> but in general, Lucas is correct that changes to opts do not cause a
>> rerender - more importantly, they are invisible to the component until
>> unmounting and remounting.
>>
>>
>>
>>
>> On Thu, 4 Dec 2014 13:48 Lucas Bradstreet <lucasbr...@gmail.com> wrote:
>> Glad to hear it. I guess I will avoid that pattern then.
>>
>>
>>
>> By the way, I am a little worried about your change-fn below, which closes
>> over data but is passed in via the opts. I believe there is no guarantee
>> that an opts update will trigger a re-render.
>>
>>
>>
>> :main-component-m {:opts {:change-fn
>>
>> #(search data true)
>>
>> }}
>>
>>
>>
>> I'm guessing that the subcomponent is being re-rendered every time data
>> changes in a way that is relevant to it, but I would watch out.
>>
>>
>>
>> I try to avoid passing in any info to opts that may change.
>>
>>
>>
>> Lucas
>>
>>
>>
>> --
>>
>> 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 clojurescrip...@googlegroups.com.
>>
>> To post to this group, send email to clojur...@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.
