@devth I don't know about a map you'd get from the request that would tell you which set of reads/mutations that would be fired. You could run the query through a separate parser to determine this set client or server-side. Something like:

(let [parser (om/parser {:read   (constantly {:value 1}) 
                         :mutate (constantly {:action (constantly 1)})})
      query [(list 'mutate/this) :read/that]] 
  (set (keys (parser {} query))))

#{:read/that mutate/this}

What is the interplay between om/Ident and om/IQuery ? I appear to have a situation where the existing of an om/Ident field changes the way an IQuery is being run.

om.next + datomic = ❤️ … It was one clever decision to match the query language with datomic pull, the combination is really powerful.

@alex-glv have you been using it?

Just working on a small personal project. Similar to trello, with oauth. It took a long while to get up to speed with so many new concepts (and om.next docs are far from great at this point) but matching server/front-end together in read/mutate decoupling is really an interesting approach.

this is one of the best resources on it I've found: https://github.com/madvas/todomvc-omnext-datomic-datascript

haha, that's funny, I did a similar thing before github introduced kanban view I was working on a chrome extension doing exactly that, also using om next 🙂

I’ve been using there https://github.com/anmonteiro/om-next-fullstack/ https://github.com/swannodette/om-next-demo

cool, thanks

Neither implement routing, though, so that was a bit tricky to grasp. Again, om provides enough primitives to implement it all, it just feels a bit cumbersome at this point.

Yeah, I think “what’s the trivial thing I can implement with my new shiny stack?” almost begs for a trello clone 🙂

yeah, filtering and querying made easy

also interesting and related: https://github.com/metasoarous/datsync

where is a set of exercises I can work through to understand the interplay of om/IQuery and om/Ident ? If I have an object and it only uses om/IQuery, everything works fine; however, when I add an om/Ident field to it, it seems to do weird things (via normalization?) to the data I'm sending to it, and I no longer understand what is going on

@qqq have some trouble fully understanding it as well but as for excersises:

http://untangled-web.github.io/untangled/guide.html#!/untangled_devguide.C_App_Database_Exercises

further the guide helps as well

@bbss: I worked through those last night (but was discussing it in the #untangled channel), unfortunately, it's about definig data, not the interaction of Ident/IQuery

right, just closest thing I know that might enlighten 🙂

guess you'll have to dive into the source!

(def hello (om/factory HelloWorld))

(js/ReactDOM.render
  (hello {:title "Hello, World!"})
  (gdom/getElement "app")
)

In the following block of code:

(ns om-tutorial.core
  (:require [goog.dom :as gdom]
            [om.next :as om :refer-macros [defui]]
            [om.dom :as dom]))

(def app-state (atom {:count 0}))

(defn read [{:keys [state] :as env} key params]
  (let [st @state]
    (if-let [[_ value] (find st key)]
      {:value value}
      {:value :not-found})))

(defn mutate [{:keys [state] :as env} key params]
  (if (= 'increment key)
    {:value {:keys [:count]}
     :action #(swap! state update-in [:count] inc)}
    {:value :not-found}))

(defui Counter
  static om/IQuery
  (query [this]
    [:count])
  Object
  (render [this]
    (let [{:keys [count]} (om/props this)]
      (dom/div nil
        (dom/span nil (str "Count: " count))
        (dom/button
          #js {:onClick
               (fn [e] (om/transact! this '[(increment)]))}
          "Click me!")))))

(def reconciler
  (om/reconciler
    {:state app-state
     :parser (om/parser {:read read :mutate mutate})}))

(om/add-root! reconciler
  Counter (gdom/getElement "app"))

seems hard to statically analyze the action function for finding out what changed

also not sure you want om to respond to every state change made in action

so suppose I did :value wrong -- i.e. I updated :foo and :bar, but I only had :value {:keys [:foo]} does this mean there are things that depend on :bar that won't be updated?

i.e. is it programmer / my responsibility to enumerate everything that could change? this seems error prone

Hmm, :thinking_face: I'm not sure of this, so someone please correct me if I'm wrong. But yeah, not gonna re-render parts that use :bar if :foo isn't also in the read.

how do I embed initial data (if none present) into the om root element? I searched through https://github.com/omcljs/om/wiki/Quick-Start-(om.next) for "init" but couldn't find it -- but could have almost sworn that I used it somewhere

you can pass it to the element directly as an argument to the component ((om/factory UiComponent) {props "stuff")

when using reconciler you could pass it to :state

there's no om/InitialState that I can inherit and then implement a (initial-state [] ... ) ?

I could have sworn I used something like that to specify initial state, but I can't find it anymore

there is initialState but it's a react thing

like so:

Object
 (initLocalState [this]   
   {:state-count 0})
  (componentWillUnmount [this]
    (println "Buh-bye!"))

the :value in mutate is a no-op

really basic question: why should I use om/transact! instead of swap!

@bbss the todo app is a good example,

@baptiste-from-paris Yeah, @madvas did a great job on that one

transact can retrigger reads swap doesnt, probably more losses of swapping, you should never need to swap! even tough swap! may at time deliver the result you are looking for.

ah, I see, "swap!" is a blackbox in terms of "what was updated", but trnasact! with queries, makes it statically analyzeable what was updated

maybe you loose too the reconciler history, well you probably do. You can swap, if you're looking for this simple architecture for rendering you may want to check out re-agent.

and this allows om to know which elems need to be updated?

yes, the components aren't dereferncing the app-state, except needed/asked for trough the parser.

which makes om fast I guess.

okay, so swap! is useful only in tutorals that walk you through the basics

after going through tutorials, I should pretty much never use swap! (unless in exceptional cases) and basically always use om/transact! ?

yes, get in the habit of using transact. You can make the overhead of transact! more concice with some macros, in untangled there's defmutation macro. But to be sure we are on the same level, in the parser you can swap as much as you want.

but don't mutate some values that the mutation wont retrigger read of 🙂

@bbss I am wondering how much the cljc can grow since he abstract datomic datastrictdepending on the platform

yeah it's cool stuff. Actual useful code sharing between platforms 🙂

@anmonteiro which PRs did you want me to look at?

https://github.com/omcljs/om/pull/844 https://github.com/omcljs/om/pull/852

@dnolen those two ^

thanks!

@dnolen OK to cut a release too?

(excuse me if you were already doing it)

yep

awesome, looking forward to it

awesome

done

@dnolen the new ClojureScript release broke Om Next 🙂

heh

we use cljs.core/js-arguments which is now private

fixing

hrm that one probably shouldn’t have been private

in Mike’s defense, it says ;; internal - do not use

yeah I probably should have looked more closely at that patch

hrm, I’m thinking all the macros marked internal shouldn’t be private

like coercive-not etc

will fix tomorrow and recut

yes

most of those macros should be public

people will need them in interop cases

yea

I agree