This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-03-14
Channels
- # arachne (5)
- # architecture (2)
- # bangalore-clj (7)
- # beginners (96)
- # boot (34)
- # braveandtrue (1)
- # cider (12)
- # cljs-dev (38)
- # cljsrn (59)
- # clojure (326)
- # clojure-dev (35)
- # clojure-greece (1)
- # clojure-italy (6)
- # clojure-russia (47)
- # clojure-spec (16)
- # clojure-uk (25)
- # clojurescript (136)
- # core-async (18)
- # cursive (18)
- # datascript (2)
- # datomic (28)
- # dirac (6)
- # emacs (4)
- # garden (3)
- # hoplon (28)
- # instaparse (1)
- # jobs (4)
- # juxt (1)
- # lein-figwheel (10)
- # liberator (1)
- # mount (3)
- # off-topic (39)
- # om (16)
- # om-next (1)
- # onyx (15)
- # pedestal (9)
- # proton (1)
- # random (1)
- # re-frame (48)
- # reagent (8)
- # ring-swagger (4)
- # rum (3)
- # specter (5)
- # sql (3)
- # unrepl (273)
- # untangled (27)
- # vim (4)
- # yada (7)
Is there any way to make a select component whose query does not compose back to root? I don't want to have to pass props through for every select, I thought I might be able to do this with an Ident.
The parser is being called but om doesn't seem to be passing props to the component. I made my own lookup table on state :select/by-id
.
I'm also adding the ident as a tailing argument to transact!
It would be a good fit for component local state but I would quite like to store things in app-state if possible.
No dvingo.
I've changed it to use component local state for now but I'd like for it to be built into app-state so I can jump across all the states.
I thought maybe the component isn't being indexed because I'm not including the query in a parent and composing to root..
if it's not re-rendering but the data is updating in the reconciler you could try a "read transact" (om/transact [:select/by-id ~id])
i've used that pattern for remotes data updates to trigger updates, haven't tried from the parser though
ah, rereading what you said, i think you'll need the select component's query in your root, you may not have to pass the data down as long as its query is present in the root
I see, in that case I'd need a huge list of idents in my root component for all the select menus in my application
you may want to look into adding a new ui->props
fn https://github.com/omcljs/om/blob/master/src/main/om/next.cljc#L2541
Oh, another hidden gem for me to abuse 🙂
haha yea, i haven't played with that yet, but i probably will get there - i'd really like to avoid having to wire all the state down the ui tree
I recently uploaded a video directed at helping people understand how we handle state, remotes, and the removal of a need for a client-side Om Next parser in Untangled. Thought it might be interesting to those of you that are thinking through the Om Next patterns. Might shed some light. https://www.youtube.com/watch?v=mT4jJHf929Q