@adammiller thanks, i already got it working.

process roots will drop all other query fragments and will return only the deepest one. Is this intended?

@deplect: er that seems weird and I thought we had tests for that, @tony.kay might know something about that as well

@deplect: you cannot have subroots...am I reading that right?

I was just experimenting with process-roots as I assumed it would keep the rest of the "tree" intact and move only the nodes tagged with query-root to the root, but I noticed that the resulting query is just the deepest node tagged with query-root effectively removing all other "nodes", also useful but not in my case.

process-roots is about removing the client UI-local parts of the query, so you can send just the bits to the server...but it is about prefix removal...thus the name.

I moved to the latest version of om.next as i was on alpha28 and saw an issue regarding this. Now I am a little confused about the intended behaviour ..

you have a tree, after all

think about REST-style routes: /questions, /questions/1, /questions/1/comments

in Om, you have more expressiveness, but you also typically tack in UI stuff in front, so yuour effective paths from root contain cruft the server need not know about

/myui/widget/panel/questions/1

I understand the principle and what is accomplished using the parsing principle. I've read all your documentation, great source of information btw

process-roots is about removing the prefix...but from a tree that has an arbitrary branching factor

subroots make no sense, since once you've found a root, the remainder of the query is, well, the query you want to send to the server

siblings are fine

even sub-roots from different siblings at different depths

there are open issues/PRs for handling a few extra cases, like unions...but the behavior needs a bit more care there

I should definitely write up more docs

yes the case I am developing is multiple remote "fragments" placed at various depth in the tree, which I want to collect and send as part of the full-query on root level, on receiving the server response rebuild the tree. I was probably hoping process-roots was something like that

@tony.kay: I’m less concerned about the misunderstanding here then the fact that the deepest query root getting lifted

instead of just ignoring subroots

@dnolen: The assumption is you're wanting to remove a prefix. The choice could go in either direction (remove the least or most). I'd have to reconstruct my thinking to say why I went the way I did.

@tony.kay: the current behavior just seems undesirable to me

at least from a concurrency standpoint where you may delay remoting

and a query root higher up may get merged in

so, you're indicating a case where I may queue up more than one call to send somehow, then merge them for a single network op later?

yes send is completely opaque

people should be able to do whatever they want/need behind it

that said this isn’t super high piority

process-roots is just a helper after all

I'll see if I can (re)construct an argument for the behavior. I wrote it down somewhere...I did a lot of thought on this one.

I also agree that it is just a helper, and ppl can easily copy the current function and tweak it to their needs even

hm, actually, there is a test indicating the subroots are ignored in the fashion opposite of what @deplect is reporting...

yeah that’s what I thought

I refactored those tests at one point, and may have broken it to give a false positive 😞

again low priority for me until Beta when we should switch gears to focus on polishing

yep...reading the test, it looks right actually

I'll send a note to myself to try out the case specifically

Eventually also need to re-visit this with respect to parameters and unions...the two open PRs get us really close

yep I saw those - will look at them when I’m out of the weeds with error handling

need any help?

If I get some time, I could sort through some of the issues, if you could point me to ones you'd like to hand off

not yet but maybe later

it will definitely need testing in projects and likely adjustment based on that

oh, I meant Github Issues

hrm #555 maybe

#550 need more information - like a some kind of suggestion about a solution

the rest I will need to sort through myself at least to understand what they are actually about

when I have time

Already made a PR for 555

I can play with 550

@tony.kay: oh missed the PR - merged

great!

that was right, then, I guess

I wasn't sure I completely understood the zipper structure

heh

another thing on the Beta list of todos, documentation on architecture for contributors

graffles would be helpful here

how it works is far more boring than people might imagine

I get most of it...the "to many" case was the bit I don't follow: how you figure out which thing in the list gets which query

sorry to intrude with a newbie question: I’m working through the last part of the Remote Synchronization tutorial (the Wikipedia autocomplete), and I keep getting an undefined function error for om/query->ast. Any ideas where I could look?

@dandorman: did you copy and paste the code or are you trying to type it in?

the latter; helps to solidify the concepts

@tony.kay: like the “to many” case of joins or unions?

however, now that I’ve done it, I’ll just copy and paste and try that; thanks

@dnolen: don't sweat it...I don't have the brainpower to deal with that right now...kinda busy...so I don't want to use your time on it

@tony.kay: ha k

well, I was initially hitting the problem after copy/pasting too; but with sufficient refreshes, clearing out the build directory, and inspecting the om.next source in Chrome’s dev tools (?), eventually om/query->ast became a thing

gonna chalk it up to weirdness in my local env

another problem was that I couldn’t get the controlled version of the search field to update its value

but by commenting out the :value query line, the rest of the flow basically worked

it’s as though om/set-query! was not enough to trigger a re-render