This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-09
Channels
- # beginners (38)
- # boot (160)
- # cider (143)
- # cljs-dev (62)
- # cljsjs (2)
- # cljsrn (3)
- # clojure (278)
- # clojure-austin (8)
- # clojure-brasil (5)
- # clojure-greece (2)
- # clojure-italy (11)
- # clojure-russia (188)
- # clojure-sg (2)
- # clojure-spec (118)
- # clojure-uk (103)
- # clojurescript (87)
- # core-async (8)
- # cryogen (2)
- # cursive (12)
- # datomic (119)
- # emacs (13)
- # hoplon (4)
- # immutant (12)
- # off-topic (12)
- # om (54)
- # om-next (5)
- # onyx (1)
- # pedestal (2)
- # portland-or (2)
- # re-frame (58)
- # reagent (18)
- # ring-swagger (18)
- # rum (4)
- # spacemacs (4)
- # specter (3)
- # untangled (65)
- # yada (25)
Hi, I'm using om/next to develop a frontend project, and there is always a question in my head when I read the om/next tutorial and wrote my own project, that is when the read-fn function in parser should take care of the query in the component, f.k.s: in the [Components, Identity & Normalization](https://github.com/omcljs/om/wiki/Components%2C-Identity-%26-Normalization) example, only the query :list/one
and :list/two
are handled, while those like name
, points
in the query of Person
not, so what's the rule of query-handling, only those in the root query?
@joseph in that sample app, since (get-person) already returns the attribute Person component need then read :list/one
and read :list/two
are enough
Is there a decent resource for going from (atom app-state) to integrating a datomic transactor?
That's my biggest hurdle at the moment.