@tony.kay thanks for the release! I sent a new PR with a few adjusts
ok.
on clojars at 0.7.0-SNAPSHOT of server
Is this incorrect?
(defui ^:once Speaker
static om/IQuery
(query [_]
[:id
:name
{:job (om/get-query Job)}])
static om/Ident
(ident [_ {:keys [id] :as args}]
[:speaker/by-id id]))
(df/load
(:reconciler @app)
[:speaker/by-id 1]
Speaker
{:marker false})
My server returns:
(defn api-read [{:keys [query request] :as env} disp-key params]
(case disp-key
:speaker/by-id {:value{:id 1 :name "foo"}}
(throw (ex-info "Invalid request" {:query query :key disp-key}))))
This results in:
:speaker/by-id {1 nil},
And in the network tab of chrome I see:
["~#cmap",[["~:speaker/by-id",1],["^ ","~:id",1,"~:name","foo"]]]
which indicates that it actually returns a name and a idHm. That looks right @mitchelkuijpers
I found a bug in load yesterday I've not reported. Could be a bug.
but that is how it is intended to work 🙂
it's intended to work with just app, is the bug I noticed. My precondition fails though
Hmm do you mean with app instead of the reconciler?
any: app, reconciler, or component
but it fails with app right now
Ah ok
make sure you've cleaned/recompiled, but I don't see an obvious problem in your code
I have to do a bunch this morning, but might have tiem to look at it this afternoon
We hit the same bug in our application. This is a reproduction. I'll see if I can pinpoint the problem
It works with load-data so we use that for now
ok, yeah load
isn't officially released yet
but it was supposed to be bug-free 😉
@tony.kay I may had found a bug on load
as well, today I was trying to load an ident and couldn't make it work with load
, seems some problem on merging, but I didn't had the chance to verify yet
@mitchelkuijpers Fixed the load bug on idents. On clojars (0.6.0-SNAPSHOT)
that was timely @wilkerlucio Just pushed the fix
🙂
@tony.kay are you thinking on removing the old load-data
entirely? I can still see it being useful, but I don't mind using untangled/load
directly (I had to use that to load ident and pass :post-mutation-params
, which currently doesn't work with load-data
)
I was just debating that
there are some use-cases where load-data is more flexible
sort-of
I'm kinda considering it a trial period. We've already found two cases where load
requires a refactor. The flexibility of specifying the query without a nested join is a nice aspect to load-data
I may leave it and just document it as a more flexible, but more bit-twiddly way to do loads. Perhaps if I remove the bits that load supports cleanly, then leaving load-data for the other cases will be nicer. It is a breaking change, though.
I don't like breaking changes 🙂
I think just dropping the :ident
parameter would make it cleaner
and the new load
does that really well (now)
I think I'll do it that way: Deprecate :ident
as a parameter, and support both. load
is generally cleaner, but load-data
is more general purpose.