On Saturday, May 24, 2014 1:21:48 PM UTC-7, Scott Thompson wrote: > The problem I've been thinking about is that Om manages a path in a vector > format for use with functions like get-in whereas zippers use a location to > represent a path. So its not yet clear to me if that will translate well into > Om. Additionally, zippers allow easy traversal of a tree which might go > against some of Om's data flow. Unless you rely on the root component to > manage movement and edits across the entire state (which seems to defeat the > purpose of modularity).
Just an update here. One thing I've had some luck with, to avoid writing a ZipperCursor, is to compose a zipper function from an `om/path` operate on the atom's data directly, typically using `reset!`. So, for example, say you have something that works with zip/xml-zip ie. {:content [{:content []}]} and you have an `om/path` such as [:content 2 :content 0], you can easily compose a function which will get you to that loc in the tree to make your edits. Here's a gist: https://gist.github.com/noprompt/6aa96a10f430a0f48de3 -- 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 clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescript@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript.