> Not possible, if it is, this is a bug. Need a minimal example of a > case where you think this happens. Make sure that you are not > accidentally putting seqs into your application state.
D'oh, this was exactly the problem...my mistake! Thanks for this clue. > The map returned by group-by won't itself be a cursor, nor the vector > values, but the values *inside* the vectors that actually originated > from the application state are! That's really all that matters. Okay, I think I understand. I guess the key is to properly structure data and components so that a collection of cursors is always getting passed into build-all, or a single cursor into build...? I'll examine where this seems to be a problem for us and see if we can structure our code to better fit this paradigm. > The removal of an explicit graft operation does alleviate some > potential issues. I also intend to overhaul how shouldComponentUpdate > equality checks are performed which should also help. > > It's not so much that you approach will not be supported, rather you > are opting yourself out of current benefits (:tx-listen state chage > deltas for example) and in the future likely rendering optimizations. Okay, I see--this makes sense. I'll think on that...perhaps we can take advantage of :tx-listen state change deltas in other parts of our app as we figure out places where it makes sense for us. But for now it's a reasonable trade-off. I am curious about the rendering optimizations you're talking about though--can you going into these any more, and why we would be missing out? Thanks for clarifying all of this--this helps tremendously David. DD (2014/04/03 21:48), David Nolen wrote: > On Thu, Apr 3, 2014 at 8:21 AM, Dave Della Costa <[email protected] > <mailto:[email protected]>> wrote: > > (def our-data (atom {:some {:path [{:id 1} {:id 2}]}})) > > (root root-component our-data ...) > > If I have a nested component that maps to :path, and then I receive an > update from outside of Om--path may have been a cursor initially, but > after I call > > ;; totally outside of Om: > (swap! our-data #(update-in % [:some :path] ...)) > > > then path is no longer a cursor. > > > Not possible, if it is, this is a bug. Need a minimal example of a case > where you think this happens. Make sure that you are not accidentally > putting seqs into your application state. > > > Similarly, if I want to process the cursor (vector) at :path before I > pass it into the component: > > ;; inside of a component's render/render-state call: > (group-by :id (get-in my-data [:some :path])) > > ...then I no longer seem to have a cursor. > > > The map returned by group-by won't itself be a cursor, nor the vector > values, but the values *inside* the vectors that actually originated > from the application state are! That's really all that matters. > > The removal of an explicit graft operation does alleviate some potential > issues. I also intend to overhaul how shouldComponentUpdate equality > checks are performed which should also help. > > It's not so much that you approach will not be supported, rather you are > opting yourself out of current benefits (:tx-listen state chage deltas > for example) and in the future likely rendering optimizations. > > David > > -- > 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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[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.
