Fork me on GitHub
#om
<
2017-06-07
>
adambrosio01:06:21

@uwo @drcode I don't think he's asking about how to do tempids, but rather should you use datomic ids or uuids. I think thats up to your and your application needs, eg: are you are going to need to interact with more than one datomic db?

danielstockton06:06:26

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.

danielstockton06:06:20

I assume i'm losing some meta on one of the queries.

uwo12:06:06

@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!

ag18:06:37

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

rplevy20:06:18

Those are the first two google results I get for: re-frame vs om next

wilkerlucio21:06:56

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

rob22:06:20

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.

rplevy01:06:44

As best as I can tell, the true distinction comes down to what tools of thought accommodate one's established ways of thinking. And I don't think I'm being uncharitable in saying that it's a rare kind of mind that can be successfully extended by om.next (at least in its current state of development and documentation). This makes it better suited to solo projects than team projects (including open source projects), because it's important that teams be able to communicate in their shared code.

claudiu05:06:27

Have you given any thought to untangled, middelway since it simplifies om-next flow a bit ?

wilkerlucio12:06:13

I use Untangled everytime I have to use Om, and I love it, it's my favorite pick by far for front-end development 🙂

sova-soars-the-sora23:06:28

@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

ag00:06:10

sova: there doesn’t seem to be anything “special” about that website. This is not the argument “you can’t do X with re-frame”. Anything that can be done with Om.Next, absolutely can be built using Re-frame. I need specific reasons why Om.Next may be better than Re-frame. I personally (after using Om.Next for months) can say: I do feel it’s nicer and switching back to Re-frame totally feels to me like a backward step. But even after months I still failed to gain expertise required to defend the point in argumentation about the merits of choosing Om.Next

ag00:06:42

I would definitely choose Om.Next for my own projects. But how do I convince people that this is indeed much better approach than Re-frame’s?

rplevy01:06:56

It seems like the fact that the expertise was so difficult to gain speaks volumes though. From what I've seen, the two frameworks are approximately equivalent in expressivity for those who have affinity to one or the other. The biggest difference is that re-frame is clear after a day to almost everyone, and I can explain my application clearly to everyone, if it's written in re-frame. I know of two kinds of programmers when it comes to om.next. 1. smart people who admit to not understanding om.next. 2. smart people who understand om.next and love it, but can't explain it clearly to anyone.

drcode02:06:03

LOL What about those of us who love it, but don't feel they understand it?

wilkerlucio12:06:10

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

gardnervickers22:06:15

@U3ES97LAC For us, building , pathopt or "incremental rendering" is a huge win.

gardnervickers22:06:50

It really raises the ceiling on when we need to start worrying about performance.

ag00:06:11

@U066U8JQJ 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