This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-12-23
Channels
- # ai (1)
- # beginners (84)
- # boot (111)
- # cider (2)
- # cljsrn (9)
- # clojure (245)
- # clojure-italy (2)
- # clojure-mke (1)
- # clojure-russia (6)
- # clojure-spec (92)
- # clojure-uk (32)
- # clojurescript (55)
- # core-async (1)
- # cursive (8)
- # datomic (19)
- # events (1)
- # hoplon (379)
- # lambdaisland (4)
- # lein-figwheel (8)
- # off-topic (115)
- # om (18)
- # om-next (5)
- # onyx (25)
- # re-frame (8)
- # reagent (5)
- # ring-swagger (1)
- # rum (19)
- # schema (3)
- # untangled (24)
How can I refer to a parametrized query as a subquery, something like this doesn't work
(defui Foo
(params [_] {:id nil})
(query [_] `({:tables/data [:desc]} {:id ?id})`))
(defui Bar
(query
[_]
(let [subq (om/get-query Foo)]
`[{:all/data [(~subq {:id "something-silly"})]}])))
if anyone can help me with this, I’d be much obliged. https://stackoverflow.com/questions/41295695/understanding-om-queries-and-ui-composition
Does anyone have ideas for handling the case when some of your query might rely on data from the server? For example, say I want a user to be able to configure some settings and this decides what UI widgets I want to render. Is it right that if I include some widgets conditionally based on the query, when they get included it will fire off another request for their reads? I don't see a way to do it without needing two requests..
The other way would be to bootstrap the config in the html to begin with so that I don't need the preliminary query.
@danielstockton Can’t you load the config and all that is needed at the same time? and then use the config for the rendering part?
Each widget has it's own query, so I'm not sure of all that is needed until I know the config
It's similar to a router under a router, I suppose
Them maybe need to load the config first.. We actually have something like this and we put some info on the html already when te page loads
That makes it a bit difficult to change settings without refreshing the page though
We merge the initial settings in the app-state and then just keep referring the app-state
We do the same with localstorage load it once in the app state and then just fire off optimistic updates
You're right...if it's optimistic on the client, its absolutely fine, thanks.
I have it half working, it shows off om's advantages quite well in that all I have to manage is what widgets appear and the queries take care of themselves with a bit of merge-with merge
magic. I don't have to have each widget make duplicate requests for the same data like I might with other frameworks...
Hi I'm wondering, in Om.next one specifies a root component via add-root! ... so then my root component should contain all of my other UI components?
Yep @sova and it should contain the entire query for all your components
Not explicitely, you use (om/get-query ComponentClass)
to defer the definition of the sub queries to the child components
But it all must compose into a valid query at root
@danielstockton I think it sounds like “dynamic routing” problem. Something I couldn’t wrap my head around for quite sometime. Then I found Compassus. You ever tried it?