This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2015-12-13
Channels
- # admin-announcements (208)
- # beginners (53)
- # boot (46)
- # cider (10)
- # cljs-dev (26)
- # cljsjs (10)
- # clojure (66)
- # clojure-dev (3)
- # clojure-russia (14)
- # clojurecup (5)
- # clojurescript (302)
- # cursive (22)
- # data-science (1)
- # datomic (10)
- # emacs (1)
- # events (2)
- # hoplon (91)
- # incanter (1)
- # ldnclj (3)
- # leiningen (1)
- # off-topic (2)
- # om (41)
- # re-frame (40)
- # reagent (78)
is the chrome debug environment expected to work with om.next + natal?
maybe this is better suited for #C0E1SN0NM but
trying to do some simple nesting of test components and just failing hard
and the lack of any debug messages is killing me
i solved my immediate problem, at least, and i鈥檓 really liking the high level design
(defn get-people [state key] (let [st @state] (into [] (map #(get-in st %)) (get st key))))
(this is from https://github.com/omcljs/om/wiki/Components%2C-Identity-%26-Normalization)
@si14: that's probably outdated
you can use db->tree
now
@anmonteiro: can you please provide an example?
(defn read
[{:keys [query state] :as env} k _]
(let [st @state]
{:value (om/db->tree query (get st k) st)}))
and a more general question: is it even worthwhile to invest time into om.next now with intention to build back-office (but production) stuff, or is it too early and I would be better off taking Reagent and hacking together something fast?
I understand that the question might be offensive, sorry about that, just really wondering about opinions of more experienced people
@anmonteiro: thanks a lot!
@si14: no problem
answering your question, it's not offensive at all. I'd say you wanna use Om Next if you find it tackles the problems you're trying to solve
really depends on your use case. If you feel Reagent is better suited for your problem domain, go ahead and use it
the problem is, I'm not really sure that my feelings are adequate here. Om Next is a bit overwhelming, but I see the intensions behind it and it seems very reasonable; on the other hand it would be a shame if e.g. API will change significantly between now and beta
on the other hand, I already know Reagent, it's very simple (at surface, that is), but it will probably not scale well for complex apps with interesting server-side story
I don't know the inner workings of Reagent so I can't provide an opinion on that
what I can say is Om's API is unlikely to change significantly
David has been very careful wrt. API changes
is there any example of remote mutations out there? It seems that it is missing from the guide
actually, that's also not done yet
here's one: https://github.com/swannodette/om-next-demo/blob/master/todomvc/src/cljs/todomvc/parser.cljs#L60-L66
@ognen.ivanovski: Should be fine according to the query syntax: https://github.com/omcljs/om/blob/master/src/main/om/next/impl/parser.cljc#L5
@dnolen: will you accept a PR adding dispatch
to om.next.server
?
@anmonteiro: I second that PR. I noticed that it was missing but forgot to do something about it.
it is a convenience, but one that also exists for the client side, so why not on the server?