Thanks Colin. My response to your points:
1) The row gets the data and then does some additional calculations on it
before displaying. If the data doesn't change, the row shouldn't re-render or
these calculations are unnecessarily done again, since they are part of the Om
render.
2) If I'm using the example of:
(om/observe owner (items))
Then are you saying I can observe just one key/value of (items)? Assuming items
is this:
(def app-state
(atom {:items {:a 1 :b 2 :c 3}} ))
(defn items []
(om/ref-cursor (:items (om/root-cursor app-state))))
I could then do:
(om/observe owner (:a (items))
and this would effectively be a reference cursor that only updates when a
specific value :a inside the (items) reference cursor updates? In other words,
if other values in (items) update, it would not trigger a re-render since they
are not the key explicitly mentioned in my om/observe. Is that the expected
behavior?
On Wednesday, March 25, 2015 at 12:09:53 PM UTC+1, Colin Yates wrote:
> Hi Andrew - my first thought is are you *sure* your performance
> problem is where you think it is? And secondly, *why* don't you want a
> row to re-render - does it have side effects or is it about
> performance?
>
> 1) My anecdotal evidence is that yes, a re-render happens if the
> content of an observed reference data changes.
> 2) Don't pass the entire cursor to the row, only pass (select-keys
> large-map [keys this row depends on]).
>
> HTH.
>
> On 25 March 2015 at 10:53, Andrew S <[email protected]> wrote:
> > I am restructuring an Om app to take advantage of Reference Cursors. I am
> > doing so because my current app, which processes, manipulates and displays
> > large amounts of data several times per second, is not running so
> > efficiently and reworking it in the "old" hierarchical manner to only pass
> > very specific cursors in an attempt to minimize re-rendering is proving a
> > logical challenge.
> >
> > I have read the Advanced Tutorial and it all seems quite nice. But i want
> > clarification for now on two things (might have more later):
> >
> > 1) Previously, an Om component would be forced to re-render if its local
> > state or its cursor into app state updated with new values, right? If
> > either of those didn't change, the component would not need to re-render.
> > If I use om/observe now, I assume that even if the cursor or the local
> > state do *not* change, the component *will* re-render if what it is
> > observing changes, right? In the Om documentation, many of the functions
> > explicitly mention when a re-render will happen, but the om/observe does
> > not mention this.
> >
> > 2) Suppose I have a large map in my app state. The values in the map change
> > often but at different times. Suppose I have a table where each row
> > reflects data for a particular key/value in that map. I do not want a row
> > to re-render unless its particular key/value changes, but not other
> > key/values in the map. The actual key/value are dynamically created and
> > removed many times during the app's runtime, thus I cannot explicitly
> > define a reference cursor for each one. What is my best strategy? Without
> > reference cursors, I could first pass the map itself as a cursor to a
> > parent component for the whole table. Then I could om/build-all over the
> > key/values for each row in the table. But this causes the parent component
> > itself to re-render when data for the rows updates, even though the parent
> > component does not care about that data -- only the row components care.
> > And if the parent re-renders, I'd think maybe all the children of that
> > parent are also re-rendering, such that all rows in the table might
> > re-render even if only one of them needs to be re-rendered? These are the
> > challenges I'm trying to work around.
> >
> > --
> > 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.
--
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.
