Clojurians Log v2
om
What should I check if a response isn't being normalized correctly anymore? I have a nested query that I added :query-root: true, process-roots and rewrite. That response is being normalized correctly but it broke another query elsewhere. If I remove process-roots and rewrite, that query is fixed but the nested one breaks.
I assume i'm losing some meta on one of the queries.
@adambros ah, right. I’ve noticed that when working with datascript and datomic uuids can be useful for referring to refs. multiple datomic dbs would have the same issue. thanks!
is there a good write-up on re-frame vs. om.next? it seems some people in my team pushing for switching back to re-frame and I need some arguments to keep om
I use Untangled everytime I have to use Om, and I love it, it's my favorite pick by far for front-end development 🙂
https://www.reddit.com/r/Clojure/comments/4i16v0/is_there_a_better_library_than_reframe_in_its/
https://www.reddit.com/r/Clojure/comments/3vk58p/a_rant_on_om_next/
Those are the first two google results I get for: re-frame vs om next
@ag I like the reasoning expressed by Tim Baldridge on this thread: https://clojurians-log.clojureverse.org/clojurescript/2017-03-26.html#inst-2017-03-26T16:46:27.678527Z
I feel like most people don't really get the Om.next design, it's understandable given the novelty ways, maybe after people get more used with Relay that might change, but for now it's mostly unfamiliar so people tend to fall back on stuff they already know
FWIW, I’m not so much interested in the nature of the proposed design/promise of Om.Next (or to what degree people do or do not “get it”) vs re-frame. I’m curious if you feel like Om.Next successfully implements these ideas to the degree that teams (who are largely not passionate about Om.Next itself) can reliably pattern-match the concepts enough to be productive.
@ag I don't have many write-ups yet but you can look at https://nonforum.com for an example site written in om.next
well, I think it's hard if you have to figure out for yourself, but if you have at least 1 person on the team that knows how to use it, teaching that to someone else is not that hard, here at company I used Om.next + Untangled in a hackaton project with someone else that has almost no experience in front-end at all, and just basic on Clojure, and in 2 days he was able to understand how to change things
@sova For us, building <http://pyroclast.io|pyroclast.io>, pathopt or "incremental rendering" is a huge win.
It really raises the ceiling on when we need to start worrying about performance.
@wilkerlucio teaching is hard when people refuse to accept different/novelty approach, when something familiar and easy to pick for them is right there. The tool that’s marketed better, has excellent documentation and bigger userbase. And there’s no documented evidence of one being much better/faster/scalable than the other. That’s very sad. Because Om.Next does have some qualities and ideas I personally like very much