This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-05-18
Channels
- # admin-announcements (7)
- # arachne (24)
- # beginners (40)
- # boot (24)
- # braid-chat (22)
- # cider (8)
- # cljsrn (35)
- # clojure (32)
- # clojure-austin (1)
- # clojure-belgium (52)
- # clojure-russia (16)
- # clojure-sanfrancisco (1)
- # clojure-taiwan (2)
- # clojure-uk (25)
- # clojurescript (112)
- # core-async (3)
- # cursive (18)
- # data-science (1)
- # datascript (7)
- # datomic (30)
- # devcards (2)
- # dirac (12)
- # emacs (4)
- # flambo (1)
- # funcool (5)
- # hoplon (146)
- # jobs (9)
- # jvm (5)
- # off-topic (4)
- # om (141)
- # onyx (22)
- # re-frame (89)
- # reagent (86)
- # ring-swagger (31)
- # rum (3)
- # spacemacs (1)
- # specter (10)
- # untangled (112)
- # yada (3)
i guess you could add a key to the props and then use (om.next/set-query! this {:params (:foo props))
before it mounts
personally I would put an :account-view
in the :ledger/data
instead of a parent telling child how to configure
I reckon it鈥檚 not a data problem I can鈥檛 wrap my head around. Simple as it sounds: I need lists of similar data where it would group each list based on a property
hm.. i did find https://github.com/not-much-io/om-tutorial-dev-cards/blob/c1df938064455d26ac44b4cd122984163a54a697/src/main/om_tutorial/parsing.cljs#L201
@jasonjckn: I think that's how you do it (but I've been out of the om loop for a few months)
(defmethod remote-read :widget/two
[{:keys [state query ast target] :as env} key _]
(println "remote-read: " key query)
(let [ast (update-in ast [:children 0 :query-root] (constantly true))]
(pprint ast)
{target ast}))
and (defn send [{:keys [remote]} cb]
(println "SEND: " (prn-str remote))
(let [{:keys [query rewrite]} (om/process-roots remote)]
(println "query: " (prn-str query))))
what's emitted from the send function is the unrerooted query, nothing changed{:type :join,
:dispatch-key :widget/two,
:key :widget/two,
:query [{:datomic/pull [:listing/title]}],
:component om-admin-v2.core/ListingList,
:children
[{:type :join,
:dispatch-key :datomic/pull,
:key :datomic/pull,
:query [:listing/title],
:component om-admin-v2.core/Listing,
:children
[{:type :prop, :dispatch-key :listing/title, :key :listing/title}],
:query-root true}]}
well i submitted a bug report https://github.com/omcljs/om/issues/684
and, warning re ast-zip there: if you zip/edit and touch children, you are of course 'on your own'
i can set :query root on the outer join and it propagates to the send function via meta data around the outer join
om/process-roots is clearly meant to read :query-root true recursively on any joins in the query expression
fix-query above is designed to update :query to match :children (assuming this has already been done for the children)
you could just touch :query instead. if you know it's a join, I dunno... (update-in [:query 0] vary-meta assoc :query-root true) or something like that?
or, yeah, you could take the :children ast's, touch them, om/ast->query them, then put that in your ast's :query?
https://github.com/awkay/om-tutorial/blob/master/src/main/om_tutorial/parsing.cljs#L226
the ast representation is redundant and om doesn't want to do unnecessary work here, I guess
eh, I dunno if it's about unnecessary work really. the representation is redundant so they've gotta pick one of :query or :children to pay attention to
(..and paying attention to :children would mean recursively converting the entire ast to queries, which is more work)
the place to look in the source is at om.next.impl.parser/ast->expr's extra boolean argument and its callsites
(side note: I do think there is a bug that query-root doesn't work for props, so.. hopefully you won't try that)
i'm trying to choose a web framework for my teams v2 product, i can't for the life of me figure out if om.next is a good choice or not for our situation, I think the lack of documentation, maybe not quite bug free yet means it's not quite ready yet, I also don't know if i can truly understand the om.next source code at this point since i'm new to cljs/react/etc
so probably reagent is a safer choice , albeit the state code could become spagetti code over the life of the project
@jasonjckn: the learning curve is relatively steep and the documentation is lacking
but in reality the project probably needs 10X more documentation than it currently has
yah, another possibility is that I own the parser backend part of the project, and I get my team up to speed on the defui stuff, which is relatively the same as just plain react no?
and I suspect if you understand om.next you can model your Reagent project accordingly
the query expression provides some element of decoupling between the ui data tree and the underlying source of the data
i find myself writing parsers like if namespace of the keyword begins with "widget" then recursively descend into the children, these :widget/foo are just for the ui data tree purposes but they don't correspond to any actual data on the backend
I don鈥檛 know what you are doing or how your trying to do it but that鈥檚 the other thing
and you can change your mind later since you didn鈥檛 write that logic into the components
yah, that's nice, maybe you change your mind that some state should persist across browser sessions
i really like the separation because it will enforce some discipline on a large codebase on how things are organized
so the whole thing is biased by all my experience doing front end stuff and needing to make changes all the time
and we can just have 1 or 2 people specialize in parsers, but the whole team doesn't need to know
dnolen: Q, the query expressions communicate 'joins' with { } but whether that's a join in the backend is completely dependent on that data store
so seems like a lot of work around converting query expressions to backend queries unless you are on datomic
@jasonjckn: there鈥檚 a lot of stuff to do even if you use datomic
but now if I want to add some new data to the frontend I don鈥檛 have to go mucking around so much with the backend
is it a bad idea to call om/transact!
inside of a client mutation?
@currentoor: seems weird to me yes
is there a function for validating whether a piece of data conforms to a query expression spec
@jasonjckn: re choosing om.next - I feel like it should be paired with projects that take advantage of it.
@jasonjckn: not for validating that a piece of data conforms to query expressions specifically, but there is validator
in factory
, which is much more general and you can implement that on top of it
I'm using it for a library catalog kiosk at work and it's been wonderful - idiomatic normalized data and queries, no weird read methods.
But porting a personal project that doesn't have idiomatic top level data/components has been a big stumbling block.
@jasonjckn: yeah https://github.com/selfsame/learnnext (lots of images in that repo)
@jasonjckn: validator
is just a function you pass to om/factory
which takes props
e.g.:
(om/factory MyComponent {:validator (fn [props] (cond-> true (not (contains? props :foo)) not)})
must return truey / falsey value
we assert
on its return val
@dnolen: just submitted this which completes the fix for #679 (joins deep in recursion; this time for union recursive queries) https://github.com/omcljs/om/pull/686
a use case that I鈥檇 forgotten when working on the first part
@anmonteiro: thanks merged!
whoa that was quick
thanks!
having to write (dom/br nil) is annoying compared to [:br], any solutions here besides rolling my own?