Clojurians Log v2

should I really be using clojure 1.7 for om.next? the tutorial seems to imply so but I hope it's not true

@matan you can use 1.8/1.9, I'm pretty sure that was just the stable version at the time the tutorial was published.

@danielstockton thanks good to know 🙂

I have a read parser which modifies the ast before sending to backend (assoc-in [:params]). This works fine on the initial read but I noticed the params are missing when I trigger a subsequent read with (om/transact! this [:read/key]). I've verified the parser is still associng the params correctly. Anyone come across this?

Am I the only one for which lighttable is unable to find the definition of #js as in

(dom/button
          #js {:onClick
               (fn [e]
                 (swap! app-state update-in [:count] inc))}
          "Click me!")))))

@matan I'm not familiar with lighttable but #js is a tagged literal: https://cljs.github.io/api/syntax/#tagged-literal

It's not a function in the usual sense, it's a reader macro

Not sure what you're hoping to see as a definition.

thanks @danielstockton I'm learning om.next in tandem with a re-cap of clojurescript, so this was helpful!

So it's a special form implemented by the cljs compiler..

@matan you could try like

(dom/div (clj->js {:onClick (fn [evt] ...) }))

@matan or (js-obj "onClick" (fn [evt] ...))

Wrote a beginner om-next tutorial. https://github.com/ftravers/missing-links

Feedback welcome.

hi! I’m following the basic tutorial on the om wiki and started to hit errors when I got to https://github.com/omcljs/om/wiki/Basic-Tutorial#rendering-a-list-of-things

is that tutorial updated?

Hi all. Quick question in case someone's seen this before… I have some data coming back from my server (using om.next.server) that's getting normalised and looking great!

{:session/user
 {:db/id 1,
  :user/email "[REDACTED]",
  :user/name "jcf",
  :user/uuid #uuid "5967e7c7-0053-4a83-95e4-51ad2ab19051"},
 :session/emails
 [[:email/by-id 17592186045423]
  [:email/by-id 17592186045424]
 ;; ...
:email/by-id
 {17592186045440
  {:db/id 17592186045440,
   :email/subject "2VVma6Cz6w1M92",
   :email/uuid #uuid "050d8769-8f2c-446b-bfe5-8cd3d3160e8c"},
  17592186045472
  {:db/id 17592186045472,
   :email/subject "83zSQGK6VLlPGAIPjm4HkFZ42uQPMnQsZ6",
   :email/uuid #uuid "7d7afd5b-9e38-4019-af20-663e7a4e35cc"},
 ;; ...

I'm happy with the :email/by-id bits showing up top-level and the idents in :session/emails. That looks right and gets passed onto the cb function provided by Om's send fn.

Problem is, the state that ends up in the reconciler is full of nils. The :session/email idents are all [:email/by-id nil], and there's a single {nil [:email/by-id 1111]} entry in the :email/by-id.

The single :email/by-id number is a real :db/id from Datomic.

Is this something anyone else has seen before?