Re-define mutations and remotes

[petterik]

From notes in code:

;; TODO: Model mutations.
;;       * Remote mutations could be a field on the Mutate type?
;;         - '[Mutate [^{:a 1 :b 2} add-foo]] <--- gross?
;;       * How do we model local mutations?
;;       * How can we do local and remote mutations?
;; Remember: Parser is a made up thing by om.next. It could be more
;;           than a 2- or 3-arity function.
;;           - It could be a set of functions.
;;             :local-query
;;             :remote-query
;;             :local-mutations
;;             :remote-mutations
;; I think it's time for input argument syntax. >:(

;; Mutations being different than a query:
;; Using list of symbols in om.next as not comfortable as
;; one would have to quote and unqoute things.
;; using a list of keywords to params seems better.
;; but a list of mutations is just [[:mutate/a {}][:mutate/b {}] ...] which could also be a map
;; So using a map or a seq of kvs should both be fine, as order can sometimes matter.
(comment

  (la/transact! this
                {:mutate/thing {:foo "bar"}
                 :mutate/other {:baz "xyz"}}
                '[Query
                  [logged-in-user [name email address repositories [url]]]
                  [feed [title content]]])

  ;; Another function for when one doesn't want to mutate anything.
  ;; Needs to exist because one should be able to call transact with just a mutate.
  (la/read! this '[Query [logged-in-user [name]]])
  ;; If one for some reason needs to construct mutates and reads together, we can have:
  (la/transact* this {:mutates [[:mutate/thing {}]]
                      :reads   '[Query [logged-in-user [name]]]})
  ;; ^ Which is called by both la/transact! and la/read!


  ;; A remote should be able to answer:
  ;; - Given a set of mutates, return the ones you take care of.
  ;; - Given a set of reads, return the ones you take care of.
  ;; ^ - For both, possibly mutated? Or is that a separate step?
  ;;     - Let's keep it separate for now.

  ;; Store the layer as is, don't break it apart. Store it similarly as in layer_v1:
  #{:layer.local/mutates
    :layer.remote/mutates
    :layer.remote/reads}
  ;; We need ot deal with execute them given a merge. Thoughts:
  ;; :layer.remote/mutates do nothing, as the information is in the reads.
  ;; So should layer.local/mutates could depend on when the layer.remote/mutate
  ;; happened in the original transaction.
  ;; hmm.
  ;; Starting to think that transact! should look like this instead:
  (la/transact! this
                :mutate/thing {}
                :mutate/no-params
                :mutate/other {}
                '[Query [logged-in-user [name]]])
  ;; Since order of mutates matter, we shouldn't put them in a map.
  ;; This would turn in to a call to:
  (la/transact* this {:mutates [[:mutate/thing {}]
                                [:mutate/no-params]
                                [:mutate/other {}]]
                      :reads   '[Query [logged-in-user [name]]]})
  ;; At parse time, we could call the parser with a validation step to see
  ;; if the mutation's params are valid.

  ;; Remotes should probably be added as something that
  ;; can get called, not just a vector of keywords that gets
  ;; passed as a target to the parser.
  ;; We could instead do:
  {:remotes {:graphql (fn [] ...)}}
  ;; Where each remote gets called for all sets of mutations and reads.
  ;; Could be defined as:
  ;; * a set of functions
  ;; * single function with arities
  ;; * function with command passed as an argument
  ;; * protocol.
  ;; If it's a protocol, we could also do one of the function alternatives,
  ;; as we could wrap the function in a metadata implementation.
  ;; Just need to define what the protocol is.

  ;; Getting closer!
  ;; Coffee time?
  )