On Thu, Apr 3, 2014 at 8:21 AM, Dave Della Costa <[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].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/clojurescript.
