On Thursday, March 26, 2015 at 2:03:21 PM UTC+11, Jamie Orchard-Hays wrote: > Thanks for that, Mike. Like I've written earlier in this thread, I've been > trying a few approaches and have been wondering what others have come up > with. (I don't need to reinvent the wheel.) > > I hadn't quite gotten as far as you've described, though I was definitely on > that path with one approach. Another I've tinkered with is using > clojure.walk, but I dislike that it touches every node. Expensive on a large > data set. Zippers don't make me happy either. > > Definitely agree with keeping data as flat as possible, but even so you can > end up with a decent tree shape, which the data structures I'll be consuming > and generating actually have. > > In my app, a Product is a Component (not a React/Reagent/Om component) that > has many Components. Each Component can have many Components or many > Substances. Even though the components are stored flat, they form a logical > tree of n-levels of Components. Components and Substances can have other > lists as well. > > So, you can see that my needs to traverse into a rich data structure are > immediate, even with flattened storage of the Components in a single list on > the root Product. > > Interestingly, last Summer I started on this with Reagent and later Om using > the unflattened data (why?--it was flat in the db!). It got turned into an > app for different data that was not recursive in any way, but I'd still > solved that problem. I turned to Om then b/c it has cursors and they solved > this problem so well that I felt it was worth the other pains involved in > using Om, so I gave up on Reagent. In a nutshell: Reagent made developing > React-style components really simple and easy, but dealing with a rich > app-data atom was such a PITA, that I switched to Om whose cursors made that > easy while making component development much more cumbersome. Since seeing > and playing with Re-Frame, I've decided to do this next project with > re-frame. > > Anyway, thanks again for the info, as it definitely helps me along. >
Yep, you've got a recursive data structure there which just naturally leads to nesting. No getting away from it. One thought: you talk about storing all the "Components" flat (even though they nest). Wouldn't that mean each Component has an "id" (unique key)? If so, do you really need to know the "path" used to traverse to the Component, or could any dispatch just reference the "id"? -- Mike -- 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.
