Fork me on GitHub

@alex-glv I believe reads should be non normalized. db->tree is called in reads and this function denormalizes.


A question on Compassus, why isn't the parser getting invoked?

(defmulti read om/dispatch)

(defmethod read :index
  [env k params]
  (js/console.debug "Read called")
  {:value "Hello"})

(defui Home
  (render [this]
    (let [text (om/props this)]
      (html [:div text]))))

(def app
  (c/application {:routes {:index Home}
                  :index-route :index
                  :reconciler (om/reconciler
                               {:state {}
                                :parser (c/parser {:read read})})}))

(c/mount! app (js/document.getElementById "app"))


@fenton so I shouldn’t do anything explicitly to normalise data to be able to use refs and idents? My problem is data gets merged into the state but it doesn’t get normalised. I am left with the actual results from the database (datomic), so I am trying to figure out if I need to do anything extra in reading, or something wrong with the query / components.


@fenton Also, I noticed that if I don’t specify my custom merge function to reconciler, I get extra key in my result map #{}
does it mean om failed to find relevant idents and normalize?


@asultanpur: because your Home component doesn't have a query


Do I need to have a query even when I’m dispatching based on current route, by letting :route-dispatch remain as true?


Your parser handler for any given route refers to the data that the component for that route needs


i have a Compassus app which has its initial state correctly normalized by the app, but when a remote is called the ui is rendered as expected but the new data is not normalized and merged back into the app state. Is this the expected behaviour?


@tmulvaney: that's not enough information


Are you calling the send callback with the appropriate query to normalize the novelty against?


@anmonteiro I'll get back to you. You may have nudged me in the right direction 😉


yep passing the novelty and the query did the job! Thanks @anmonteiro


I didn't realize the callback took query as an argument as well. The example at seems to only involve passing the novelty.


This callback is multi-arity. With one argument, pass the novelty. With two arguments, pass the novelty as the first argument, and then pass a query as the second argument.


OK. So the fourth arg to merge (query) is passed in via the cb. I was wondering why it was nil whilst trying to solve my original problem. Things are making more sense 🙂


what are the pros and cons when using IAtom as :state in compared to just plain map?


i'm exploring the example in's Thinking With Links and the state is not normalized when i change init-data to IAtom


i tried to setting :normalize true in option but the state is not normalized


(def my-reconciler (om/reconciler {:state init-data ;; atom :parser (om/parser {:read read}) :normalize true }))


the init-data is (atom {...})


@mavbozo :normalize true in the reconciler instructs Om Next to normalize remote responses, not the initial state


if you want to pass an atom to the app state, you need to pre-normalize it yourself


using>db for example


Getting Uncaught ReferenceError: React is not defined after defining some queries in ident+query only components, found this issue but could not resolve by adding om.dom


@anmonteiro cool, (om/tree->db SomeList init-data true) returns

{:current-user {:email ""},
 :items [[:item/by-id 0] [:item/by-id 1] [:item/by-id 2]],
 {0 {:id 0, :title "Foo"}, 1 {:id 1, :title "Bar"}, 2 {:id 2, :title "Baz"}}, #{:item/by-id}}


is it okay to leave in pre-normalize app-state?


hello guys, little typo in the doc of om-next here => we can easily we

Finally notice that because queries are just regular ClojureScript data we can easily we get some extra bit of information. We tack on :favorites to each subquery. We will be writing shared favoriting logic shortly.


ok, it was written ‘DO NOT EDIT’ but ok


the DO NOT EDIT part refers to content, not typos


to prevent people with insufficient understanding of Om Next to introduce mistakes in the tutorials


I just noticed that this code ex from the doc bugs (if someone can confirm)

(defmethod read :dashboard/items
  [{:keys [state]} k _]
  (let [st @state]
    {:value (into [] (map #(get-in st %)) (get st k))}))
error =>
:dashboard/items is not ISeqable
to make it work =>
(defmethod read :dashboard/items
  [{:keys [state]} k _]
  (let [st @state]
    {:value (into [] (map #(get-in st %) (get-in st [k])))}))


@anmonteiro Your advice to use browserify to exclude react was spot on- It solved my problem (with a couple of extra tricks to tweak the output of browserify) thank you so much!


@baptiste-from-paris Hmm.. in the tutorial it mentions "Of these the only one that should be at all surprising is DashboardItem. Instead of returning a vector it returns a map." .. but I'm gonna do some investigating and see