is there a way to pass through IQuery and IQueryParams? I'd like to write a higher-order-component to re-use some functionality

@tobiash you can write "pure" components without queries

not sure if it's what you're looking for

the ListView in this example doesn't have a query, for example: https://github.com/omcljs/om/wiki/Components%2C-Identity-%26-Normalization#something-to-look-at

i want to refactor code that subscribes to events in componentDidMount and then unsubscribes accordingly in componentWillUnmount

mh, ok instead of wrapping the "higher-order component" around my component, i could wrap my child components with it. But I think hoc is a nice pattern

maybe that would be a nice addition to om.next?

it might be that I'm looking at these things too much from a React perspective, but I keep running into these issues: I have navigation bar that also displays some action buttons, depending on the current route. How do get the button presses to the current route? Currently I use a core.async channel, but that means that every route component has to subscribe/unsubscribe to it

maybe it would be nicer if the route component implemented some protocol to receive the events and then I would not need the sub/unsub boilerplate

I am trying to make server-side rendering in om,next, and have an exception creating the server reconciler, if someone has a clue: http://stackoverflow.com/q/41082153/1327651

@nha that's because stuff in the reconciler has circular references to it

Oh ok - but can I work around it?

yeah, with remove-method and prefer-method

the problem is just about the printing

I am trying something like that right now: (prefer-method print-method om.next.Reconciler clojure.lang.IRecord) (does not work - never used prefer-method before)

(prefer-method print-method om.next.Reconciler clojure.lang.IDeref) does not throw, but then does not seem to change anything

Anyway, since this only printing putting it in a var is fine.

So far I tried:

(prefer-method print-method om.next.Reconciler clojure.lang.IRecord)
(prefer-method print-method om.next.Reconciler clojure.lang.IDeref)
(prefer-method print-method rethinkdb.core.Connection clojure.lang.IPersistentMap)
(defmethod print-method om.next.Reconciler [r writer]
  (print-method {:config (:config r)
                                    :state (:state r)} writer))

Am I barking at the wrong tree?

I've gotten that to work before, but I don't quite remember how

I remember also using remove-method

I'll try that, thanks

Ok that will be for another day. How can I render-to-str a CompassusApplication. (in clojure)?

@nha hrm, I don't think I've ever tried it 🙂

but you should be able to compassus.core/mount!

with a nil target

then pass the return of that to render-to-str

Thanks, will try 🙂

@nha PR welcome adding a test for it, even if it works

the Compassus tests run in Clojure too

yes I saw that - hence I assumed it worked server-side as well

hmm it seems to throw (compassus/mount! app nil):

Unhandled java.lang.ClassCastException
   clojure.lang.PersistentHashMap cannot be cast to java.io.PushbackReader

@nha the whole stacktrace would be more helpful

hrm weird

looks like either: 1) a problem with your parser function 2) a bug in Compassus 🙂

could be my parser to be honest

migrating from cljs to cljc - I may have things lying around

I'll try doing that in the compassus repo

right, there are a few hurdles you may have to go through

in any case, I'm happy to know you're using Compassus!

Well I'm just experimenting 🙂

(I am not sure I understand the different tradeoffs of the different routing approaches)

Compassus is just a library around the union query approach

But yes I am trying to get server-side + compassus + bidi althogether

not much else there tbqh

Yes I saw that. previously I had a transact! in a key :app/route. looks similar

Something like that:

(componentDidUpdate [this _ _]
                      "Sync state -> url"
                      (let [{:keys [current-route]} (om/props this)]
                        (when (not= current-route (url->route js/location.pathname))
                          (pushy/set-token! history (route->url current-route)))))
  (componentDidMount [this]
                     "Sync url -> state"
                     (let [listener (pushy/pushy #(om/transact! this `[(route/update {:value ~%}) :route])
                                                 url->route)]
                       (pushy/start! listener)
                       (set! history listener)))
  (componentWillUnmount [_]
                        (pushy/stop! history))

By the way, I see you do not use componentDidUpdate in the bidi mixin?

@nha it's just a simplistic example

up to you to implement it if you want

there's actually no will-update mixin

so PR welcome for that and did-update!

aha ok 🙂

re: om/next, i have multiple components (to be added via add-root!), all contending to read/mutate the same application state atom (and reading & updating the same keys therein). if I use the same reconciler for all components i seem to get errors like "no queries exist for XComponent", etc. is the correct thing to do to create separate reconciler for each component? that doesn't seem right, though. i want component X to modify, say, :some-data, and have Y update as necessary in response. i would think a singular reconciler would need to orchestrate that? what am i missing?

@atdixon No, one reconciler should work fine. You are probably not following the 3 golden rules of OmNext queries: 1. There must be at least one query key for every component (you can't just say "the parent and this child both use the :foo query endpoint"- Each component needs its own endpoints in the query tree) 2. The query for a parent must call om/get-query on all children to populate its own query 3. The render function in the parent must pass props to the children in exactly the same manner as described in the parent query.

In the past, when I was breaking these rules, I got the "no queries exist of XComponent" error.

Thx for the reply @drcode -- I believe I'm following those rules. my problem seems to stem from trying to add seperate roots (add-root!) but sharing the same reconciler and state. Can I have more than one root for the same state? For the same reconciler?

Oh you got me there, didn't realize you have multiple roots... I don't have any insight into that use case...