Fork me on GitHub
#om
<
2016-12-23
>
ag02:12: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"})]}])))

danielstockton07:12: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..

danielstockton08:12: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.

mitchelkuijpers08:12: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?

danielstockton08:12:05

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

danielstockton08:12:52

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

mitchelkuijpers08:12: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

danielstockton08:12:37

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

mitchelkuijpers08:12:32

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

mitchelkuijpers08:12:06

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

danielstockton08:12:30

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

danielstockton08:12: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-soars-the-sora09:12:43

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?

danielstockton09:12:11

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

danielstockton09:12:23

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

danielstockton09:12:41

But it all must compose into a valid query at root

ag18:12: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?