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.
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...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...
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.