Is it possible to have a single default read function. My thinking is, is om-next query syntax enough to actually query 'some' data source. I'm guessing that the data should be in a specific form if this is possible.

@fenton if you use multimethods for read and mutate just specify a default like (defmethod read :default …)

@denik i'm wondering what the implementation of a default read function would look like. I know about the :default part. Also wondering if this is a silly idea or not...

Are there any examples of remote reads that require token authorization? Looking for ideas on how to pass the token through to send.

Also, is there any need to return an action function on remote mutates? Do people generally call action in their merge fns?

@fenton

(defmethod client-read :default
  [{:keys [state query ast] :as env} k params]
  (let [st @state]
    {:value (om/db->tree query (get st k) st)}))

https://github.com/omcljs/om/commit/75c9133fef315ce6d5477f2edd37c873e5cf2f2e still throws index out of bounds for us

in our case update-path is an ident in a vector (length 1) and the path a 3 item vector of the actual component path

@anmonteiro could this be a bug?

@denik: can't know without seeing an actual failing case

Hey guys, has anyone thought about truly "componentizable" architecture based on Om.Next? Let me try to explain what exactly I mean. Imagine a "base" of the app, "core" of the app as library and components as libraries (potentially built by different teams). So I could just add a component (library), that contains everything related to a certain aspect of the app: ui-components; read/mutate methods (for both client-side and back-end); tests, etc. Ideally it would be awesome to be able to add and remove certain things declaratively (in runtime). Let's say you build a component as a lib, push it to Clojars, then add that dependency to some sort of manifest of the base app and voila - app renders the added stuff even without having to re-deploy the app. Possible at all?

@ag I have some opinions on that, I have an idea that I call "readers", the readers are supposed to be re-usable endpoints into the graph definition, still maturing the idea, but it's working fine on two projects that I'm working, I talked a little about it on the untangled channel, if you wanna check it out: https://clojurians.slack.com/archives/untangled/p1478298741003803

if you follow the link the rest has some code examples

could anyone explain why this doesn't work? I'm trying to better understand unions:

(def data
  {:a [[:b-by-id 1]
       [:e-by-id 1]]
   :b [:b-by-id 1]
   :b-by-id {1 {:d 5 :f 6}}
   :e [:e-by-id 1]
   :e-by-id {1 {:g 7 :h 8}}})

(om/db->tree [{:a {:b [:d] :e [:g]}}] data data) ;; => {:a [{} {}]}

@whitecoop the key on the union query need to match the key of the ident, try querying [{:a {:b-by-id [:d] :e-by-id [:g]}}]

that's how Om will figure the branch to go, using the first component of the ident

@wilkerlucio ah! that worked