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.
