Fork me on GitHub
#om
<
2016-08-16
>
exupero00:08:53

Are there any recent examples of using Om Next with remote synchronization? I’m having trouble getting it to rerender after calling the callback passed to the sender function. The data comes back and gets into the state, but doesn’t show until I trigger a rerender in some other way.

anmonteiro01:08:55

@exupero: some reasons why it could be happening: 1) you didn’t specify keys to re-read after the transaction 2) need to add an ident to the component that will present that remote data so that Om Next can figure out what to re-render automatically

exupero01:08:49

1) In this case synchronization is triggered by set-query!, not a transaction. Can I specify keys to re-read, or will it just use the component’s query value? 2) Possible since I’m not using idents. By my reading of the Remote Synchronization Tutorial, I shouldn’t need them (I’m doing essentially the same thing).

anmonteiro01:08:16

@exupero: you can also add a 3rd argument to set-query!

anmonteiro01:08:23

a vector specifying the keys to re-read

anmonteiro01:08:03

e.g. (om/set-query! this {:query [:foo]} [:bar]) <- re-reads :bar

exupero01:08:12

Thanks, but no luck. It looks like when reconciling it’s not coming up any components to rerender. My key may be confusing it; it’s a vector: [:things/by-query “…”]

exupero01:08:34

Looks like the problem is in key->components. My query goes in, but the following doesn’t find any components: ((:ref->components extfs) indexes k) (om/next.cljs:1189). Not sure what the problem is.

grzm14:08:39

Just pushed a blog post on some issues I was having developing om client and server code in the same project using Figwheel and Reloaded, with Reloaded picking up client cljc files during (reset): http://seespotcode.net/2016/08/16/figwheel-reloaded/

calvis18:08:19

having some issues during testing - it seems like the return value from om/add-root! (and thus the :root in the reconciler's :state) has no query associated with it when target is nil I believe this causes the behavior of tree->db using the (:root @(:state reconciler)) (e.g. during default-merge) to differ depending on whether target was nil or not during om/add-root!. not sure how to work around this for tests other then to find somewhere to really mount it

anmonteiro18:08:45

@calvis: hrm, is the behavior still the same if you (om.next.protocols/add-root! reconciler Root nil nil) ?

Joe R. Smith19:08:17

What is the proper way to recursively call the parser when you have union queries? e.g., If I have a root query such as: [{:app/route-data {:route1 [:thing :another {:some [:other :stuff]}] :route2 [{:blah [:foo :baz]}]}}]. In that example query I have a read parser method for :app/route-data that recursively calls the parser with its query, the union query, another read method for :route1, which recursively calls the parser with its query, and finally a read method for :some, which returns {… :remote (assoc ast :query-root true)}. I’m noticing two problems, the query passed to the read method for :route1 is nil and I never make it out to the server.

Joe R. Smith19:08:25

Is there a good example of recursive calls to the parser, with remotes + unions?