Oh, it might have very well been me being to much of a newbie to even understand what was going on, so please don't take the claim too seriously.

I believe that it had something to do with it being relatively much work to update things deep in a tree.

Like, if I have Model -> Users -> User -> WallUpdates -> WallUpdate -> Comment, and I want to make an update to a comment, I'd have to do a lot of code writing. Is that true, or did I just miss the magic function that helps me do this?

But I'm now realizing that maybe, if I want to "manually" do that, I'm just doing it wrong - this should partly be what Om's cursors are meant to avoid, right? (this, and locality to components)

In general, if it helps you as feedback, I found Mori a little difficult to approach, having no Clojure experience. I suspect that some more examples of typical usage patterns at the top of the docs would do a lot. Like, which methods are supposed to be commonplace, and which ones are more for edge cases? What kind of things am I supposed to do all the time, what kind of things should I wish to avoid except in these and these cases?

FWIW, I feel like the same holds for Underscore/Lo-Dash's docs, except it's been less of a problem for me because I'm more familiar with typical usage patterns of mutable data structures.

Ah, Mori provides a few useful functions for updating nested structures - update_in and assoc_in.

http://swannodette.github.io/mori/#assoc_in

http://swannodette.github.io/mori/#update_in

While we're on the subject, here's my super nitpicky complaint abour mori: the use of snake_case when almost all JS is camelCase.

In the simple little project where I used mori, I did this:

    const {
      get,
      conj,
      js_to_clj: map,
      clj_to_js: pretty
    } = mori;

But I bet you lose a surprisingly large number of JS devs due to just having the "wrong" names. Maybe I should publish a camel-case-mori module on npm...

This is because mori is written in ClojureScript. For the most part, all mori is doing is exporting pieces of Clojure so that the native JavaScript environment can access them[1]. In Clojure, the naming convention is "foo-bar", and the cljs compiler translates that to "foo_bar".

I can't imagine changing the cljs compiler or adding a piece to mori that must be maintained is important enough for this. I'd imagine Swannodette's answer would be "you should use ClojureScript anyway" :)

[1] -- https://github.com/swannodette/mori/blob/master/src/mori.clj...

I don't think it'd be a huge issue in any case, probably just a case of providing a handler for name conversions. Not sure if it's worth the extra code lying around, but anything that potentially makes cljs a better actor in the js world is nice.

> I've tried as much as possible to supply an API that doesn't stray too far from conventions JavaScript programmers are used to from underscore, lo-dash, etc.

This is a nitpick but JavaScript convention is to use camelCase, not underscores, and it feels weird whenever you encounter a library that uses them, usually it's a library that is written by Ruby or Python programmers. It's irritating if it's a library you need to use a lot.