This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-04-07
Channels
- # beginners (41)
- # boot (38)
- # cider (17)
- # cljs-dev (52)
- # cljsjs (3)
- # clojure (200)
- # clojure-italy (8)
- # clojure-russia (50)
- # clojure-spec (28)
- # clojure-uk (45)
- # clojurescript (28)
- # core-async (9)
- # core-matrix (2)
- # cursive (16)
- # datascript (15)
- # datomic (50)
- # dirac (5)
- # emacs (20)
- # figwheel (8)
- # flambo (2)
- # hoplon (10)
- # incanter (1)
- # jobs (1)
- # leiningen (2)
- # lumo (26)
- # mount (171)
- # off-topic (22)
- # om (54)
- # onyx (2)
- # pedestal (27)
- # re-frame (10)
- # reagent (12)
- # ring (27)
- # ring-swagger (3)
- # rum (2)
- # slack-help (1)
- # spacemacs (134)
- # specter (6)
- # sql (15)
- # testing (20)
- # uncomplicate (5)
- # unrepl (49)
- # untangled (9)
- # yada (29)
Hey so I just picked up clojure and i’m making a fun little app with it, but I hit a snag in frontend land. I can’t’ figure out exactly what the difference between om and om.next is. So… what’s the difference?
@benbot om is a thin wrapper around react, and has a forgiving learning curve. It doesn’t take much to learn om if you already know React. Om.next tries to do a bunch of things like incremental rendering, an async render loop, components that specify what information they need, among a bunch of other bells and whistles.
@levitanong so is om.next to om like re-rame is to reagent?
I’d like to say it’s sort of re-frame++ to reagent. 😛
but yes, built in
Do you think I should be using om.next right from the start, or mess around with om by itself first?
@benbot IMHO Any gains you get from om won’t translate into om.next, so if you intend to pick up om.next at any time in the future, you might as well start with it.
@benbot not sure what you mean by the final js thing.
@levitanong Since om.next is built into om, if I don’t use anything from om.next, will that code still be in the compiled JS
also I don’t really like how om.next uses objects 😞 avoiding objects is why i started learning clojure in the first place lol
@benbot ah, i think you’ll have to go on advanced compilation to get rid of the extraneous code. (Will need someone more qualified to confirm this)
Ah, you’re talking about the static om/IQuery
stuff?
You can implement methods on objects that were defined with defui
it all seems very NOT clojure-y
@benbot but you have to go through that stuff with om anyway. reify
protocols are a fundamental part of clojure/script, and are a big reason why they interoperate well with java/script. They’re OOP-esque, sure—but they’re constrained to very specific areas of the code you deal with, so it’s manageable.
@carter.andrewj No, the merge
doesn't know where the data came from (AFAIK), but typically what you want to do is have your send
(which does know the remote) massage the data as necessary into a uniform format before passing it to the send
callback.
@carter.andrewj Stay tuned, I've got some work coming that should make it easier. 🙂
@peeja Thanks, man 🙂 I've got the first bit working now (by precisely the route you're suggesting - so good to know I'm headed in the right direction). Interesting on the coming-soon teaser 😛
I was literally just typing another question while you replied...
I'm currently trying to get om.next to create a nested set of similar objects - I don't know how many objects there will be ahead of time, so I structured the data as a hierarchy (that gets built from the results of send
, as mentioned above). However, to get om to render these components, I needed to add the following to the query: {:children (om/getQuery ThisComponent)}
- which has resulted in the app trying querying itself forever and exceeding the maximum call stack size.
I was hoping this would be handled lazily behind the scenes and so just work as-is, but it appears that's not the case
Ah-ha! I was hoping there was a way to get this sorted 🙂
actually ...
?
Or are you pausing for effect? 🙂
Thanks, mate 🙂 I had a moment of "Oh, god - how do I get around this one..." there
So [:foo :bar {:children ...}]
will read :foo
and :bar
off the current thing and then off each of its children, and their children, and so on
You can also limit recursion to a particular depth with a number, like [:foo :bar {:children 5}]
A word of warning, though: while that's the syntax to express what you want, there's only so much that Om itself does for you to make that happen (at least for now). Your parser code is going to be responsible for some of it.
Yes, there's something not working perfectly currently - but it's not throwing any errors, so presumably I just need to take a closer look at my data structures
Currently, I build the nested map manually and call tree->db
on the full result
Will that work as expected? Or would I need to call that at a lower-level of the process?
@carter.andrewj tree->db
or db->tree
?
db->tree
will handle the recursion for you. tree->db
is for normalizing during merge, and shouldn't care about recursion.
tree-db
But all I need it for is normalization of the data, once it's been received/structured, (I think...)
@peeja And indeed it does! (after some mis-steps with seqs (that should have been vectors) and malformed idents, etc...)
Thanks again
@carter.andrewj Sweet! Glad to help!