Am I correct in thinking that there’s nothing inherently special about the query grammar; the “magic” comes from interpreting the use of that grammar in our readers in order to best traverse our data?

How off am I? a little or a way?

that sounds about right

check this out https://github.com/awkay/om-tutorial

his query section addresses that topic

Yeah, I’ve been through that a couple times, it’s a good read : )

@anmonteiro: do you have plans to extend om-css to work with sablono as well?

@denik: something to think about

Contributions welcome too!

@anmonteiro: you’re saying the first case is the bug, that the template should erase the union?

@anmonteiro: oh missed the later bits in that backlog - yeah bug

@dnolen: I ended up figuring it out by myself by looking at the query-template union tests

submitted issue #652 and PR #653 with the fix

great thanks

@anmonteiro: what about pseudo-selectors?

has anyone written anything here or elsewhere about doing aggregation in an om.next query? Imagine a list of boards which each contain a list of todos, and your component wants to display each board’s name and percentage of todos complete. Any opinions on a clean way to handle that in the parser?

do you have more than one way in mind?

@denik: aren't they supported by garden itself?

if you've got a failing case, open an issue and I'll gladly look into it!

@tomjack not yet. The one thing I’m observing is that querying a synthetic attribute like :board/percentage, which doesn’t exist anywhere in the app state, is going to clutter up my parser function significantly. Previously my read parser fn for :board/list is just (om/db->tree query (get st key) st), which is great and generic and works regardless of what the component query is, resolving joins and idents. But a naive approach to calculating :board/percentage there will lead to a mess of conditional logic, especially if I later need another aggregation attribute.

I was doing something similar, but for me it was just (defmethod read :board/percentage [env k] ...)

the method for :board/list didn't need to know about :board/percentage. not sure if I'm confused

one thing I had wondered about, though: if you do a mutation and specify just :todo/completed? in the reads, om will not know that your :board/percentage also needs to be read. whereas if you just query for all the todos and aggregate in render, it will

I think. again, likely confused

(at the moment I am back to aggregating in render, because it is plenty fast enough for me..)

I guess I see why it's unclean for you. (om/db->tree query (get st key) st) is a read function fit for tutorials, but I never use anything like that

Splitting it out to a separate read function like you said is desirable to me. I’ll try something like that. I’m not averse to writing code, I’m just trying to think big

I should probably stop talking. I currently have this for keys like :board/list

(defn read-many-ref [env k]
  (let [{:keys [state data query parser]} env
        st @state
        data (or data st)
        refs (get data k)]
    {:value (if (contains? data k)
              (into []
                (map (fn [ref]
                       (parser (assoc env :data (get-in st ref))
                         (if (map? query)
                           (query (ref 0))
                           query))))
                refs))}))

but I notice that e.g. untangled-web does something like what you have

I haven’t looked at untangled source yet. I’ll check it out

was looking at untangled.client.impl.om-plumbing/read-local

the read functions which receive a query but do not recursively call the parser always confused me

I figured they were just tutorial simplifications

@tomjack: No need for recursion...`db->tree` does that for you

Unless you need some kind of custom thing (e.g. parameter interpretation) there isn't much it won't do

@dnolen: I'm seeing expr->ast lose query-root metadata in joins

that’s possible

might have missed some case

willing to merge a PR that adds :query-root to the AST in join->ast?

that's where I've tracked it down to

whenever the join has query-root metadata, add it to the resulting ast map

@dnolen: issue needed or just PR?

PR is fine

thanks

also happy to cut a an Om release today with the latest fixes

OK cool

I'll send you a PR in a few minutes, it'd be cool if this one was included as well

@dnolen: #655 fixes it

thanks

merged

cool, thanks

@tony.kay: it won't use my parser, right?

What is "it" in this context

db->tree

correct

I think maybe I understand. if your read function just uses db->tree, then using db->tree makes sense. but as soon as your read does anything different for some query stuff, then you will want to ensure that db->tree is not used with queries containing that stuff?

@tomjack: indeed, you'll use om/db->tree whenever it works. However some cases (like parameterization), needs you to do more stuff manually

so when I write (defmethod read :board/list ...), I assume that I know nothing about the query. maybe the query contains parameterization or other weird stuff, maybe it doesn't, I dunno. so still not sure I'd ever use db->tree -- guess I'm probably still confused

if I have a whole app with no weird query stuff, then I can see using db->tree

I guess "there is no weird stuff in queries for these referenced entities" is something I could know

What're the advantages of db->tree over a 'general' recursively parsing solution? Speed, I wonder?

@dnolen: my problem wasn't solved with the join->ast patch, even though that was problematic too

I've narrowed it down to focused-join (which focus-query calls) losing the metadata

this happens in index-root and then full-query returns queries without metadata

working on a patch for this one

I've opened #656 to track this issue, as I'm not sure I'll finish the patch today

k

@dnolen: was actually a simple one, PR #657 fixes it (also tested in my project and the issue is now gone)

@tomjack Personally, I avoid parameters on queries overall and use app state instead. It doesn't mesh perfectly with the remote story in the pure Om world, but it works for the UI, and in our apps we augment the server queries on transmission instead of in the UI.

this eliminates the need for custom read parsing altogether. You end up doing a little bit of work elsewhere, but so far it has been a win

For example, instead of using parameters to do pagination, we instead do pagination as a "view"...e.g. state in the app database that refers to the items to show. The UI query always just asks for the view. Then mutations can create that view as needed in reaction to events like "next page". Remote loading integrates very nicely with this, even when loading a page at a time.

This is also the approach #C0PULSD25 takes

All that said: I do see a real reason to write a more complex parser on the server. Parameters are pretty important there.

@anmonteiro: merged

i find myself using computed properties to communicate from children to parents, but using core async for communicating arbitrarily across the UI tree. Is that the right approach?

@seanirby: Not in Om next

The UI should be pure functions, the mutations abstract. Trigger all of the changes with a single mutation. The UI updates cross-tree use follow-on transaction reads

no core async or app event systems needed (or desired) at the UI level

(om/transact! this '[(app/f) :properties-to-trigger-renders])

The "follow-on reads" are keywords that appear in UI queries. Om will re-render anything that queries the provided keywords, allowing you to do it via data dependency instead of UI structure.

tony.kay: the use case im talking about is like the one in your overview

the friend button communicating up to the friends widget

communicating from child to parent is a callback, that then typically does a transact. The reason you use a parent for that is to make sure things like ownership re-rendering happen without needing follow-on reads

where do I use async for that?

you don't

but you use computed properties right ?

I just updated the untangled tutorial with a cross-tree exercise in the Mutation exercises

So, I'd recommend playing with that, since it uses the follow-on reads I just described

computed is about passing calculated things to children. callbacks being a primary example

doing mutations in a parent is important when that parent is the owner of a collection of children (e.g. a list that needs to re-render because of entry/exit of a child)

The follow-on reads are necessary when some part of the UI is unrelated, and just needs to re-render in response to an arbitrary mutation.

tony.kay: i appreciate the detailed response, I'll check out that tutorial.

is there any good way to see how your web app looks in both a browser and mobile device at the same time?

and have it automatically update with any change?

figwheel makes developing on the browser a breeze, but I would also like to see how things look on mobile safari/chrome. I currently have a port forwarded so I can view my site on mobile but there is no figwheel connection to it

adamkowalski: have you checked out the phone emulators in chrome?

yeah I have and they are nice, but for whatever reason it seems like I get subtle ui differences in real devices then whatever the emulators show me

especially on safari it seems like there is a different default css for certain things

like rounded corners randomly appear in my elements and I have to specify borderRadius: “none” lol

adamkowalski: yeah they're not perfect, but for me they suffice for initial devleopment

yeah, they are definitely still nice. thanks for the tip

i just wish we had something like browsersync or something