This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-06-07
Channels
- # aleph (19)
- # aws (1)
- # beginners (75)
- # boot (28)
- # cider (1)
- # cljs-dev (12)
- # cljsrn (20)
- # clojure (350)
- # clojure-argentina (1)
- # clojure-chicago (2)
- # clojure-dev (2)
- # clojure-russia (5)
- # clojure-spec (2)
- # clojure-uk (14)
- # clojure-ukraine (3)
- # clojurescript (68)
- # component (87)
- # core-async (25)
- # core-logic (13)
- # cursive (4)
- # data-science (72)
- # datascript (59)
- # datomic (15)
- # defnpodcast (7)
- # emacs (33)
- # hoplon (5)
- # immutant (73)
- # jobs (21)
- # klipse (6)
- # lumo (14)
- # off-topic (26)
- # om (23)
- # onyx (6)
- # parinfer (37)
- # protorepl (4)
- # re-frame (13)
- # ring (2)
- # rum (3)
- # spacemacs (2)
- # specter (22)
- # sql (47)
- # uncomplicate (10)
- # unrepl (79)
- # untangled (66)
- # vim (47)
- # yada (17)
@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?
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
https://www.reddit.com/r/Clojure/comments/4i16v0/is_there_a_better_library_than_reframe_in_its/
@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.
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.
Have you given any thought to untangled, middelway since it simplifies om-next flow a bit ?
I use Untangled everytime I have to use Om, and I love it, it's my favorite pick by far for front-end development 🙂
@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
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
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?
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.
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
@U3ES97LAC For us, building
, pathopt
or "incremental rendering" is a huge win.
It really raises the ceiling on when we need to start worrying about performance.
@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