Fork me on GitHub

anmonteiro: that actually isn't formatted well, let me try again


Now I want to see the queries of your components simple_smile


anmonteiro: The query in question is marked near the bottom


@seanirby: let's do it like this, if you could


provide the defui implementation without the Object methods


and the initial state you're passing in


to the reconciler


@seanirby: hrm your data is partially normalized


that's where the error is happening


right the code data has idents for the face


why is that an issue?


i guess i assumed that it would work since the data i needed normalized was normalized without issue


well calling tree->db from the root assumes you want to normalize everything


im not doing that explicitly, but is that what happens when I set :normalize true ?


you might want to normalize your data outside of add-root! and pass it as an atom to the reconciler


ok i'll try that


i.e. normalize what's not normalized


merge what's normalized


pass that as the state


i wanted to model this data as how I imagine it would appear from the server. i figure having it partially normalized would be the most efficient


is that a wrong approach?


really depends on what the server is returning, doesn't it? simple_smile


anmonteiro: thanks a lot for taking a look


anmonteiro: well its got to be something else. I tried both normalizing only whats necessary like you suggested and I also tried passing in 100% non-normalized data. Both cases result in the same error


I have the following query in a children component: (query [this] '[(:repository {:query ?language}) (:code {:language ?language :repository-full-name ?repository-full-name}) (:language) (:repository-full-name)]) How can I query this in the root component? If I try to do in the root component: (query [this] [(om/get-query children/Children)]) It doesn't work and gives me: No method in multimethod 'haxlife.query/read' for dispatch value: (:repository {:query nil})


If you had a :default multimethod or used a case statement you would be able to debug exactly what is coming in. That might give you some feedback/understanding of how to 'catch' all the keys. You could stick with a case statement as well. It does seem tricky to be catching them when parameters are involved. I've never used parameters so can't help much more.


@cjmurphy: I can see that the issue is with (:repository {:query nil}), but I wonder why the params aren't getting passed as they should


@dnolen: there's an issue (#605) for

(focus->path (focus-query [{[:person/by-id 2] [:id :name]}] [[:person/by-id 2]]))
;; => [:person/by-id] (instead of [[:person/by-id 2]])
may I ask what's the reason behind the current behavior? It seems to me that the change required to make this work is minimal (just remove this line: )


So, I’m trying to create a form with ON (as the cool kids call it) and a variant of set-query! routing approach outlined by @anmonteiro, the sub component uses local state to keep the intermediate/edited values and I keep seeing "Uncaught #error {:message "No queries exist for component path (pp.core/Root pp.views.integration/EditIntegration)", :data {:type}}” in a variety of situations such as the submit handler and previously when trying to set state at various times in the lifecycle/process … unfortunately a simple example that exhibits the error might be hard to produce (I’m messing with the query in the root view and the local state in the sub/form-editing view) but what might that error mean and what might cause it? Anybody have a good example of a more involved form (than the todomvc example) or a better approach? Thanks in advance.


@anmonteiro: looks like alpha31


@juliobarros: normally that error means wrong query structure


Ok. Thats possible. I’ve tried different variations of this approach and the current version manages to navigate to the form with the selected item and then gives that message when I try to edit a field. With my tenuous understanding the query is not being changed just the state and the field that renders that piece of the state. … I’ll have to investigate further.


@anmonteiro: btw, thanks for that article. Is there an approach that you would “recommend”. My first thought was that the union query would prefetch data we might not need, and subquery seems to have a that refs limitation.


@juliobarros: I'm happy to have a look at the queries for the 2 components you mentioned and help you figure out what's wrong


wrt. the routing article, the subquery approach is definitely not for all cases


the set-query! approach seems to be the most popular, although I have to say I like the union approach best


and you don't need to prefetch unneeded data. If you have the current route in your app-state you can filter the query branches in your parser


Thanks for the info. I may try to implement the union approach to see how I like that. And thanks for the offer, let me study my code a bit more, I could be doing something obviously wrong. My thought was “Its complaining about the query, but I’ve already navigated to this component and modified the query. I’m only trying to mess with the state now … what could be the missing piece”. Thanks again.


Hello all, does anyone has (at least newbish) example of query parser for some SQL db, instead of usual Datomic based examples?