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.
