@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
  Object
  (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

:om.next/tables #{}

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

Yes

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 https://github.com/omcljs/om/wiki/Remote-Synchronization-Tutorial seems to only involve passing the novelty.

@tmulvaney it's buried in here https://github.com/omcljs/om/wiki/Documentation-(om.next)#reconciler-1

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 om.next/reconciler compared to just plain map?

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

i tried to setting :normalize true in om.next/reconciler 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 om.next/tree->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 https://github.com/omcljs/om/issues/475

@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]],
 :item/by-id
 {0 {:id 0, :title "Foo"}, 1 {:id 1, :title "Bar"}, 2 {:id 2, :title "Baz"}},
 :om.next/tables #{:item/by-id}}

is it okay to leave :om.next/tables in pre-normalize app-state?

hello guys, little typo in the doc of om-next here => we can easily we https://github.com/omcljs/om/wiki/Queries-With-Unions

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.

@baptiste-from-paris feel free to edit

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

@anmonteiro done

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

ok

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

:dashboard/items is not ISeqable

(defmethod read :dashboard/items
  [{:keys [state]} k _]
  (let [st @state]
    {:value (into [] (map #(get-in st %) (get-in st [k])))}))

from => https://github.com/omcljs/om/wiki/Queries-With-Unions

@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