Clojurians Log v2

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})

(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}))))

:speaker/by-id {1 nil},

And in the network tab of chrome I see:

["~#cmap",[["~:speaker/by-id",1],["^ ","~:id",1,"~:name","foo"]]]

Hm. 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 😉

@ag has joined the channel

@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.

@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