That's what I thought - thanks.

On 3 November 2014 13:53, jack james <[email protected]> wrote:
> On Monday, November 3, 2014 3:53:45 AM UTC-6, Colin Yates wrote:
>> The performance problem was due to me incorrectly mutating the data to the 
>> component. Rather than:
>>
>> (om/build-all child-component (map (fn [child] (assoc child :selected? (= 
>> (:id child) selected-id) :selected-row-fn (fn [p] (om/set-state! owner 
>> :selected-id (:id p).....)) child-data)
>>
>> I now do:
>>
>> (om/build-the-component data
>>   {:fn (fn [p] (assoc data :selected? (= (:id child) ...))
>>    :opts {:selected-row-fn (fn [p] (om/set-state! owner :selected-id (:id 
>> @p)))}})
>>
>> In other words, the lesson I am learning is that the cursor really wants to 
>> be domain orientated and change as little as often.
>>
>> Am I right in thinking that for component instance specific immutable data 
>> (e.g is it selected), use :fn. For component class level data use :opts 
>> (e.g. selected callbacks). For global data there is always access to 
>> (om/root {:shared...}) but that isn't applicable in this case?
>>
>> Thanks.
>>
>> On Sunday, 2 November 2014 23:29:19 UTC, Mike Haney  wrote:
>> > Sounds like a IE8 issue.  I've never seen anything like that low 
>> > performance, even on mobile.  Are you using any polyfills or shims?
>> >
>> > Check out the section "Browser Support and Polyfills" here: 
>> > http://facebook.github.io/react/docs/working-with-the-browser.html
>
> a child component, when receiving data ("props") from a parent component, 
> will compare the data to the data it previously received.  if the data has 
> changed, the child component will re-render.  the props it receives will 
> always have been passed through the function in :fn (provided to om/build or 
> om/build-all in the parent component).  so any transformations in that 
> function will always participate in the child component's determination to 
> re-render (or not). for example, if your function in :fn assoc's a new unique 
> id to the props every time it is called, the child component will re-render 
> every time it receives props.
>
> anything the child component receives in :opts is not evaluated for the 
> re-render-or-not decision.  if you put values in :opts, and those values have 
> changed but the props have not, the child component will not re-render.
>
> because of this distinction in how child components process the two, it 
> generally makes sense to put a callback function in :opts, and a transforming 
> function in :fn.
>
> --
> Note that posts from new members are moderated - please be patient with your 
> first post.
> ---
> You received this message because you are subscribed to a topic in the Google 
> Groups "ClojureScript" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/clojurescript/eEa4FOEUN6A/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> [email protected].
> To post to this group, send email to [email protected].
> 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 [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/clojurescript.

Reply via email to