Fork me on GitHub
#om
<
2016-11-09
>
fenton03:11:43

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.

denik04:11:21

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

fenton05:11:28

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

danielstockton09:11:18

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

danielstockton09:11:58

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

denik13:11:36

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

denik13:11:26

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

denik13:11:59

@anmonteiro could this be a bug?

anmonteiro15:11:21

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

ag19:11:36

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?

wilkerlucio22:11:33

@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

wilkerlucio22:11:52

if you follow the link the rest has some code examples

whitecoop22:11:30

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 [{} {}]}

wilkerlucio22:11:37

@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]}}]

wilkerlucio22:11:15

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