# om

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

ag 04:17:48

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"})]}]))) ```

danielstockton 09:34:28

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..

danielstockton 10:25:04

The other way would be to bootstrap the config in the html to begin with so that I don't need the preliminary query.

mitchelkuijpers 10:34:32

@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?

danielstockton 10:35:05

Each widget has it's own query, so I'm not sure of all that is needed until I know the config

danielstockton 10:35:52

It's similar to a router under a router, I suppose

mitchelkuijpers 10:44:49

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

danielstockton 10:51:37

That makes it a bit difficult to change settings without refreshing the page though

mitchelkuijpers 10:53:32

We merge the initial settings in the app-state and then just keep referring the app-state

mitchelkuijpers 10:54:06

We do the same with localstorage load it once in the app state and then just fire off optimistic updates

danielstockton 10:55:30

You're right...if it's optimistic on the client, its absolutely fine, thanks.

danielstockton 10:57:41

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...

sova 11:08:43

Hi I'm wondering, in one specifies a root component via add-root! ... so then my root component should contain all of my other UI components?

danielstockton 11:16:11

Yep @sova and it should contain the entire query for all your components

danielstockton 11:17:23

Not explicitely, you use (om/get-query ComponentClass) to defer the definition of the sub queries to the child components

danielstockton 11:17:41

But it all must compose into a valid query at root

ag 20:51:26

@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?