I was looking for something like this, found this thread, and tried my hand implementing a Zipper Cursor.
It's my first time digging into the om internals, so my thinking might be a bit off. https://gist.github.com/minikomi/15a58adbaaa28bacd953 Some notes - * I hit a problem trying to allow build-all. I know I need to implement ISeqable.. but I'm unsure of how to do so.. In a loop, calling clojure.zip/right, and using it to build a sequence of ZipperCursors? * I decided to pretty much not use the path variable, and just have -path return zip/path. For korks I went with :up, :down, :left, :right etc which are callable on the zippercursor and which correspond to the appropriate zipper movements. Might be to obscure? Considered using the zipper functions themselves as korks.. * transact! isn't working yet. Mainly because I'm still am not sure how the value of state is propagated to the value after transact* has finished. * I'm not convinced this is a good fit, since - as Scott says - it seems to go against a lot of the benefits of using cursors.. Joel's approach building on cursor paths but with zipper-like-movements, and a separate :selected state stored .. somehow .. representing the current "pointer" seems like it might gel better with Om. In summary.. a good learning experience for me but far from usable yet I'm afraid. Any pointers or discussion are most welcomed! On Wednesday, June 25, 2014 12:59:33 PM UTC+9, Joel Holdbrooks wrote: > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
