Anyone have a method to re-read (from a remote) after a remote transaction? First transaction returns a token and I want to trigger a remote re-read to fetch some data that requires authorization.

@drcode that's pretty much what i've been doing thanks, but felt sort of wrong, so i wanted to confirm, thank you so much!

Under which circumstations would om.next/component? return false on a component passed to om.next/add-root! as soon as I add a query implementation to it? I’ve suddenly been getting this error this morning and haven’t figured out what it might be yet.

Seems like -om$isComponent is dropped in the instance of the root component I’m passing in. How could that happen?

Oh, I think I know what’s going on - I’m calling om.next/app-root before root-render has rendered the component.

And root-render isn’t called for some reason.

@jannis: or you're getting an element back and not a component

Are you passing nil as a target to add-root!?

Well, if I set my own root-render, it isn’t called.

Nope

I checked for that

The only other option I'm seeing is if you return an empty result from the parser

Then it won't render

Yeah, and I’m returning {:value {....} :remote true}.

That's weird. If you can produce a minimal case it'd be cool

@danielstockton: did you ever open a Compassus issue about your problem the other day?

I won't be able to check it for a few more days and I'm afraid I'll forget if there's no issue

i didn't no, i'll open one now

@danielstockton: thanks! Please link your demo project too

https://github.com/compassus/compassus/issues/24

@anmonteiro Extracting a minimal case may be impossible. What’s odd is that this only happens if I add a query to the root component. If I don’t, then it just renders, root-render is called etc.

It just looks like the result of parsing might be empty

I'd bet on that horse

I’ll double check that again. I did check it before because that was my guess as well after looking at the implementation of add-root!

@anmonteiro Ok, that was it after all! Thanks 🙂

👍 what did I win? 😉

Glad you figured it out

Would a warning be a good idea if the root query returns {:value nil}? I’ve added one to the application now but I would’ve caught this much earlier if Om Next had logged a “Root query result is nil” error instead of (or (reconciler? x) (component? x)) failed.

I don't know if that'd be useful or not

You may actually want to return nil

To wait for the remote response before rendering

Right

Probably something that deserves to be documented thoroughly rather than anything else?

Perhaps starting with the FAQ

@anmonteiro I have a query question: Say I have an app that has several levels of list views and detail views. The detail views show more information about a selected item on the list. Right now, since I have several list-detail pairs at varying levels of depth in the app, I’ve opted for using links to store information on the selected states of these lists, and the app just gets the linked information in their queries to display the details. Ideally, the list-item (let’s call them stubs) views should have smaller queries, and shouldn’t even reference anything beyond the name. I mean, if you have a list of school-stubs, the school-stubs shouldn’t list the classroom entities in the queries, right? It should just be the school-detail that contains the queries asking for classrooms (which in turn have classroom-stubs and classroom-details, the details of which should only have queries for student entities) The problem is, when I go about it that way, the normalization fails. The normalization seems to only expect looking at the school-stubs, and seeing that there are no references to classrooms, stop at the school level. The links are ignored. So if I want proper normalization, I have to include all the references in the stub level. Problem with this is, the queries become unnecessarily large, and incur a performance penalty. Now I’m trying to think of a way out of this. 1. The most direct route it seems (though the most tedious) is to manually normalize everything the way I want it to, so that I can structure the queries to be properly lean. 2. I could make a separate query at the root specifically only to normalize, and be lean everywhere else. This would make initial load long, but if I don’t ask for that query again, it won’t happen again, and things stay lean. (Not sure if there are any gotchas here though, as I have yet to try it. I worry there might be some query complaints for duplicate stuff.) 3. If the structure of the app were flatter, I figure people would most likely suggest using IQueryParams. Is having a query like the below going to work like I want it to? Will it result in the same problem as with links? Somehow I feel as if this will be problematic anyway.

[{:system/schools [:school/id :school/name]
 ({:system/selected-school (om/get-query School)} {:school-id ?school-id})]