Just to add: one really shouldn't pass anything to :opts that changes
during the lifecycle of the component. The component will *not *see these
changes. I've also observed some problems if opts changes (components
getting unmounted and remounted), so best to avoid it altogether if
possible.
On 3
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:
That's what I thought - thanks.
On 3 November 2014 13:53, jack james jack.jackson.ja...@gmail.com 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
On Sunday, November 2, 2014 10:47:13 AM UTC-6, Colin Yates wrote:
(om newbie, but getting less so :))
[overhead]
Is there any overhead for a react component at runtime? If I have a single
component which emits a bunch of li, is there any cost to having each li
be an instance of a
On Sunday, November 2, 2014 10:47:13 AM UTC-6, Colin Yates wrote:
(om newbie, but getting less so :))
[overhead]
Is there any overhead for a react component at runtime? If I have a single
component which emits a bunch of li, is there any cost to having each li
be an instance of a
