@anmonteiro nice! what strategy did you end up taking for issue #7? (reconciler option)

@levitanong: ended up associng, one of your suggestions. It became possible because of some other design decisions

@anmonteiro Awesome! Glad it turned out well.

hrm … pondering now if queries should support clojure.spec

You in Bratislava yet David?

@anmonteiro I think I found a solution. Instead of modifying the ast to get the union select (almost) working, I made it possible to supply a query override to the recurse-remote function supplying the query of only the selected part of the union. It seems to work, but I need to do some cleanup and testing before I know for sure. Thanks for leading me in the right direction!

Sorry if it’s a stupid question, but… it’s a good practice reference a dom element y the will-mount section?

@rackdon AFAIK, you should be referencing a dom element in did-mount. You will probably not get anything in will-mount

and what happen if I need the element in the will-mount? should I put it in the state?

why do you specifically need it in will-mount?

is there any reason why you can’t just migrate all the code to did-mount?

I render a map with an api values, so it can changes over the time….

I have to put all the functions in the will-mount, but one of the arguments it’s the element where I’ll print the values...

@rackdon but why not put those functions in did-mount?

most of the time, any code you’d put in will-mount is perfectly valid in did-mount

ahhhhh ok, I thought that go loops must be in will-mount….

yeah, go loops can be in did-mount also, as far as I know. Just don’t put them in render 😛

😅

hi, I’m getting "next.cljc:1964 Uncaught #error {:message "No queries exist for component path <path> :data {:type :om.next/no-queries}}”}. I don’t really understand what that means, or how to fix it

Are there any docs on what exactly can go in a query, and what the constraints are? I feel like that would help me use om next much more effectively

did you just update om? I got this and it disappeared after cleaning and recompiling.

@anmonteiro I’m experiencing something strange with om.next + clojurescript 1.9.293. om.next + clojurescript 1.9.229: If I place a println inside a (query [this] …), it properly outputs to console. om.next + clojurescript 1.9.293: neither println nor console.log outputs to console in things related to queries. (parser, send, etc…) But print functions inside render work properly.

Not seeing this behavior here with cljs 1.9.293 though I’m running om snapshot at the moment

Something I've never attempted, is it possible to do multiple :send calls so I can have different remotes using different http headers and uri-s?

I see printing to console that the :send callback is all gathered to one. Can't see quickly how to tell which :remote to use which http call.

@anmonteiro Should om normalization work with :route-dispatch false? I didn’t see a test for it, and I wasn’t sure how that was intended

If I do (om/tree->db MyAppPage init-data true), om normalizes correctly

Where MyAppPage is the component that I give to Compassus

Sorry I may not understand something about the existing tests

Trying to write one / reproducing

Looking like a bug in my remote - sorry to ping

Yeah, I can’t figure it out. If I feed my init-data as :state to the reconciler, it normalizes

If I hardcode my send to do (callback init-data) it doesn't

I’ll try to make a small example

Why can’t you reuse queries? (assert (nil? c) (str "Query violation, " x , " reuses " c " query”))

How are you reusing them?

I’m trying to make SPA navigation work, and I’m calling om/set-query

apparently you should only set-query if it changes, but I’m more asking why it’s bad. Largely because I don’t understand how omnext works

Are you setting the query with a query from another component?

yeah

When om gets the query from your component, it adds metadata to it so it knows which component it came from

yes, I understand what it’s doing. I’m asking why

Sorry not typing/thinking fast enough

It then uses the metadata on the query to re-lookup the component if it needs to

The first use case that comes to mind is when it auto-normalizes your data

I’m not very familiar with the om next internals, but it has to do something there to go from query to the component’s ident

I think it also uses that metadata to quickly find updated components when data changes

Have to run but I think that’s the gist

Hope it helps

(Btw, I just realized you said about navigation; check out compassus)

(I assume you’re trying to set your root component’s query to a “page” component’s query? compassus is trying to solve that problem)

(otherwise you’ll have to re-root your query and use process-roots)

@jonsmock sorry I don’t understand your question. Happy to look at a minimal repro though to help you figure out what’s wrong!

(might have to wait a few days though, since I’m at euroclojure)

@anmonteiro: Awesome, have fun! Yup, I'll put something together.

from the components, identity, normalization tutorial: [{:list/one ~subquery}] What does a map inside a query do?

all of this https://anmonteiro.com/2016/01/om-next-query-syntax/ should be a part of the official docs