Fork me on GitHub

@amy_lowe Are you using bidi to match routes? I have something like this:

(defn set-route!
  [{:keys [handler route-params]}]
  (let [current-route (compassus/current-route (compassus/get-reconciler app))]
    (when-not (= handler current-route)
      (compassus/set-route! app handler {:params {:route/params route-params}}))))

(def history
  (pushy/pushy #(set-route! %)
               (partial bidi/match-route bidi-routes)))
Then the app-state will have a :route/params key that I can access in my parser.


Thanks @danielstockton. I also need the query to go to a remote. Would you then manually manipulate the ast that goes to the remote?


Yep, that's what I'd do.


Ah, that's what I'll do then. Thanks for the help!


To be clear, you don't need to define IQueryParams and add it to your query, like in the above example. You just pull it out of app-state in your parser and add it to the ast. Presumably, you'll get the id passed to your component anyway with the :db/id read.


Yeah, if I took the app state approach you mentioned, I agree.


My first instinct was also to use IQueryParams but it doesn't work, there is no way to pull things out of app-state. Those values should be static defaults and updated at runtime.


Yeah, I'm actually thinking I don't need them... yet. 🙂


In Clojure (not ClojureScript), how can I check that a given component implements a protocol? I have a question (asked there regarding om next *Clojure* protocols. Example:

(defprotocol my-protocol
  (aaa [this] ""))

(defui MyComp
  static my-protocol
  (aaa [this] []))

(satisfies? my-protocol MyComp) ;; false
(satisfies? MyComp) ;; false
Scanning through the source, seems like the intend is to support it (?)


I guess what I am asking is: is there an equivalent of implements? in clojure for components?


Actually I don’t care specifically about protocols, is there a different way to extend component behaviour with om?


I have been reading docs and playing with a sample app to better understand what gets re-rendered following a transact!, with and without follow-on reads. My current understanding is that: a) In a transaction with only a mutation (eg '[(age/inc)]) • the component referenced by the transaction will be rendered, along with any of its children whose properties have been changed. • if the component referenced has an ident, then any other component with the same ident will be re-rendered b) In a transaction with a mutation and follow-on read of an ident (eg '[(age/inc) [person/by-name "tom"]]) • as above for a) • in addition, any component with the ident in the follow-on read will be rendered, along with any of its children whose properties have been changed. c) In a transaction with a mutation and a follow-on read of a keyword (eg '[(age/inc) :insurance/premium]) • the Root component will be rendered, along with any children in the component tree whose properties have been modified. Although c) works fine, I was expecting the same optimizations as in a) and b) in that the rendering would only be performed on the components explicitly referenced by the transaction and follow-on reads. Can anyone correct me if my understanding of a), b) or c) is wrong, and if it's not, point out why in case c) just rendering the components which use the keyword in their query would not be correct?


@craigmalone one other thing you might want to try is ’[(age/inc) [:insurance/premium _]]


@craigmalone I think you may be jumping to a conclusion on c) too fast


@chris-andrews The case I was testing with something like '[(age/inc) :insurance/premium] was updating a node lower in the UI tree, where the keyword is not a top-level key. My understanding of the '[(age/inc) [:insurance/premium _]] ident follow on read is that :insurance/premium would have to be a top level key (or at least supported as such by your read functions)


what actually happens (in the function) is that Om Next will try to find the complete query for the key you passed as the follow-on read


@anmonteiro I saw that, which results in a correct read/set of read for the key. But then when it puts a set of components or keys in the :queue for reconcile! to process for rendering, it is always using the top key of the query returned by which then always resolves to the parent component for an update.


@anmonteiro Sorry I meant "Root" component not "Parent" component.


hrm interesting


that might be right, yes


@craigmalone do you have a minimal example I can look at?


it's probably just an oversight that we can fix easily


@anmonteiro I can put the sample app up in github and give the link. It's pretty small. I also played around with a minor change to transact* locally, where instead of the putting the top level key of the resolved full query in :queue I put the original follow on read keywords, and this gives the selective update behavior I was expecting. I will add that to the github readme if it helps.


@craigmalone you can probably do that with :easy-reads true in the reconciler


please make the example as minimal as possible thanks


@anmonteiro When you get the time, I have put the sample app in Thanks.


@craigmalone sorry I'm not gonna look at that


that's not a minimal example at all


I know what the issue is, you can make a 25-line example showing it off


@anmonteiro OK, sorry, I will reduce it and update.