If those calculations are very inexpensive then maybe consider storing them directly in the app-state? I would be surprised if you can observe just a subset of a reference cursor (no idea really), but if you can't then just create a parent which observes the entire cursor and delegates to the actual component with just the keys it needs.
Again though - why don't you want those calculations to be done again, is it simply performance? If so, have you proved it is too slow? BTW - have you looked at re-frame - it solves exactly this problem perfectly (based on my 20 minutes reading it). On 25 March 2015 at 12:02, Andrew S <[email protected]> wrote: > 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. -- 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.
