I've updated the example to show how to dynamically add resolution capabilities to all cursors in an application: https://github.com/swannodette/om/blob/f63af72522f0a0045edbada19259b6b17f5d1dcf/examples/two_lists/src/core.cljs
I'm starting to think this approach is very promising - this is already heading in the direction where I believe it can deliver independent addressability without really adding anything in the way of new features to Om itself. However determining the tradeoffs and uncovering what helpers/tools are needed to make this approach easier to adopt is going to take some time to shakeout. David On Thu, Oct 2, 2014 at 8:54 PM, Todd Berman <[email protected]> wrote: > Very interesting! > > I like the use of specify to create the collections, it makes a lot of sense. > > How would you extend it so that instead of: > > {:list0 [:a :b :c] > :list1 [:d :e :f] > :items > {:a {:text "cat"} > :b {:text "dog"} > :c {:text "bird"} > :d {:text "lion"} > :e {:text "antelope"} > :f {:text "zebra"}}} > > you would have: > > {:list0 [:a :b :c] > :list1 [:d :e :f] > :items > {:a {:text "cat"} > :b {:text "dog"} > :c {:text "bird" :children :list1} > :d {:text "lion"} > :e {:text "antelope"} > :f {:text "zebra"}}} > > Where you use list0 as the root node, and have the item-view recursively > render child lists. > > That is the part that I am most struggling with how to express without > exposing the root atom. > > It seems like in theory, you could use something like a prewalk to convert it > into the data structure you want, but that seems super heavy, and it doesn't > allow you to load list1 on the fly easily. > > That actually brings me to a semi-related question. Is there any way to > create a cursor to a path that doesn't exist yet, but will/may in the future? > > --Todd > > On Thursday, October 2, 2014 5:12:53 PM UTC-7, David Nolen wrote: >> I spent some time thinking about your problem today and it's leading >> >> me towards something which may address it and the numerous variations >> >> of this problem. At the moment I only have the following short code >> >> snippet - it uses specify in some interesting ways that I think people >> >> may be overlooking: >> >> >> >> https://github.com/swannodette/om/blob/fcf6d866e95f5765c0d500887cb6b48f32683205/examples/two_lists/src/core.cljs >> >> >> >> Feel free to ask any questions you may have. Once I've played around >> >> with this approach a bit I'll probably collect my thoughts into a >> >> blogpost and likely some kind of tutorial. >> >> >> >> David >> >> >> >> On Thu, Oct 2, 2014 at 4:39 PM, Todd Berman <[email protected]> wrote: >> >> > I am in the middle of writing my first large OM/CLJS app, and have run >> > into something that feels wrong, and I am curious if other people have >> > come up with better solutions for it. >> >> > >> >> > I am writing a CMS-type app that allows you to edit/create data objects >> > that are stored in various lists. Originally, I was storing them in an >> > atom like: >> >> > >> >> > {:lists { >> >> > "list 1" [{ ... } { ... }] >> >> > }} >> >> > >> >> > However, that causes some issues when items moved from list to list, so >> > instead I started storing them like: >> >> > >> >> > {:lists { >> >> > "list 1" ["id1", "id2"] >> >> > } >> >> > :items { >> >> > "id1": { ... } >> >> > "id2": { ... } >> >> > }} >> >> > >> >> > This generally works, but feels a bit gross, because now om components >> > that show the list of items must have a reference to their own data, but >> > also the items themselves in order to generate cursors to pass to om/build. >> >> > >> >> > As I got further into it, it has gotten a bit uglier (because I added a >> > datatype that included a list of items of its own type), which is why I am >> > asking if anyone has any better solutions to an issue like this? >> >> > >> >> > I could expose the root atom in shared state, but that sounds just like a >> > different bad idea. >> >> > >> >> > Any thoughts? >> >> > >> >> > --Todd >> >> > >> >> > -- >> >> > 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.
