This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-07-06
Channels
- # admin-announcements (2)
- # boot (51)
- # bristol-clojurians (1)
- # capetown (14)
- # cider (4)
- # cljs-dev (3)
- # cljsrn (23)
- # clojure (76)
- # clojure-gamedev (2)
- # clojure-germany (2)
- # clojure-greece (2)
- # clojure-hk (5)
- # clojure-poland (1)
- # clojure-quebec (3)
- # clojure-russia (19)
- # clojure-spec (7)
- # clojure-sweden (10)
- # clojure-uk (77)
- # clojurescript (42)
- # clojurex (5)
- # core-async (40)
- # cursive (12)
- # datomic (58)
- # editors (1)
- # events (1)
- # heroku (1)
- # hoplon (4)
- # jobs (6)
- # jobs-discuss (1)
- # ldnclj (2)
- # lein-figwheel (1)
- # leiningen (5)
- # om (66)
- # onyx (51)
- # other-languages (80)
- # proton (20)
- # protorepl (12)
- # quil (3)
- # re-frame (3)
- # reagent (18)
- # spacemacs (14)
- # untangled (78)
- # yada (16)
@anmonteiro: I ran into another issue that I think is compassus related. I was able to reproduce it in a small(ish) example, although in the example it doesn't present in quite the same way.
https://github.com/cmcfarlen/compassus-route-params/blob/master/src/route_params/core.cljs
#error {:message "No queries exist for component path (compassus.core/ui_24151 route-params.core/ItemDetailsPage route-params.core/Item)", :data {:type :om.next/no-queries}}
cljs$core$IFn$_invoke$arity$2next.cljs:1286:89
om$next$full_querynext.cljs:1255
cljs$core$IFn$_invoke$arity$1next.cljs:1265
om$next$full_querynext.cljs:1255
om$next$default_ui__GT_propsnext.cljs:1802
om$next$protocols$IReconciler$reconcile_BANG_$arity$1next.cljs:1777
om$next$protocols$reconcile_BANG_protocols.cljc:11
fnext.cljs:834
@cmcfarlen: got it running, how should I repro?
then not an issue at all 馃檪
So just open and save the source file. But that isn't necessary in my app. I'm not sure the difference
if it鈥檚 a reloading issue, that鈥檚 not a bug
I鈥檝e seen that same stacktrace with plain Om too
after a figwheel reload
you have to write reloadable code if you want that to work with Figwheel
otherwise you鈥檒l have to hard refresh the browser
In my app, if I point the browser to "/item/3" then I get the error, but if I load the list and click a link it works fine.
that does sound like a bug then
I wonder how we could go about reproducing that
I noticed that when its working, the om/path to the component that complains is [::compassus/route-data :item], but when it fails it is [:item-details :item]
So the route key is part of the path instead of the union key in the compassus generated component
I think ::compassus/route-data
should be part of the path
if that鈥檚 what you鈥檙e saying
can you repro this behavior in the example you linked?
might it be because there鈥檚 no server involved here?
Perhaps. I have to go back to the server to load some related data on the focused item, but I use data in the item to do the second load. I thought maybe that was the issue, but I'm not sure anymore
@anmonteiro: If I ensure the app is only mounted once, then of course this example doesn't break on reload. The same doesn't fix my app however as it fails on the first load. I'll keep looking and let you know what I find out.
@cmcfarlen: right, makes total sense
Alright, I鈥檒l wait for the repro, thanks!
This is a kinda cool example of using compassus with bidi/pushy and remote reads though. So we have that going for us, which is nice.
@cmcfarlen: that鈥檚 awesome news
happy to link to your app in the Compassus README if it鈥檚 something public or open source
@peeja: Yes. Goes underneath Object in your component (just like render). And takes this as first arg like all the others under Object.
@anmonteiro: I was finally able to reproduce my error. If the local-read
for the :related
returns nil or {:value nil}
then the error happens.
when I send mutation to om.next.server, I always get returned the name of the mutation method with a map. Is there a way to handle the merge into the app state in such a way that the mutation method doesnt become a key?
Are query-less components going to be able to transact soon? We鈥檙e running into perf issues because parent-components have such large queries. Or is there a way to not implicitly include the rereads for the entire query of the transacting component?
if I transact! on the reconciler, and don't include any keys in the query expression, is nothing rerendered? even if in the mutation I update app
@denik did you hear that transact will support query-less components? why do you want to modify the app-state but not query for the new state? Om wouldn鈥檛 re-render your app because it didn鈥檛 re-query the state, so I鈥檓 not understanding why you want to transact from a queryless component
@jasonjckn: the whole app is re-rendered if you transact on the reconciler, from what I understand
@ethangracer: ok i think i'm observing that
@ethangracer: so including keys in the query expression is only relevant if I transact on a component
@ethangracer: do they have to be root keys, keys found in subqueries?
yes, follow-on reads only apply if you want to re-render something that isn鈥檛 a child of the component that calls transact
they can be any key found in the query, or any ident
yeah! super handy
good question
i鈥檇 have to look at the code
it gets a query so I imagine it may try to use that
then again ,that data might not be on screen yet
rather, the components that use the data being merged
in which case the indexer wouldn鈥檛 know what components to re-render
so it probably re-renders from the reconciler, possibly specific components if it can find them in the indexer. that would be my best guess without verifying in the codebase