hi guys, I have weird case when i expect it to work but it doesn't

(defmethod read :dom-com/props ;; << root query
  [{:keys [parser query ast target] :as env} k params]
  (parser env query target) ;; << recursive call to sub queries
  ;; when I return {:remote true} here, it hits server just fine.
)

(defmethod read :project/page ;; < sub query
  [{:keys [state parser query ast target] :as env} k params]
  (prn "it goes here")
  {:remote true})

@nxqd: I have the same problem. I did a really really nasty workaround by diving down into the query and checking if it needs {:remote true} in my corresponding query to your first there. Many kittens died and I hope there is a better solution.

Just query->ast and checking the dispatcher-keys. But as said.. a hack<tm>, and I'm looking for a real solution myself. Great to see others in my rocky boat though

@jannis: thank you, that makes sense now

@nxqd: @nando FWIW, that approach should work

here's an example extracted from an app of my own:

(defn recurse-remote
  [{:keys [parser target query state ast] :as env}]
  (let [v (parser env query target)]
    (if (or (empty? v) (nil? target))
      {:value v}
      {target (update ast assoc :query v)})))

(defmethod read :dom-com/props
  [{:keys [parser query ast target] :as env} k params]
  (recurse-remote env))

@anmonteiro: cool, less hacky. I do however still have a similar hack in my reconciler :send method where I dig into the query arbitrarily to extract query parameters for the xhr call. any idea on how to clean that up as well?

It "works" right now as my queries are similar, but very far from ideal.

@nano I'm pretty sure that's exactly what process-roots is for: https://github.com/omcljs/om/blob/master/src/main/om/next.cljs#L1371-L1376

Is their a Todo MVC for Om next, if possible with Datomic backend? The one I found does not seam to work. https://github.com/swannodette/om-next-demo

Or could somebody explain to me how it works.

its a bit out-of-date but the best example im aware of

why does it not seem to work?

I load core in type (dev-start) in the repl. I seems to start, but when I go to localhost it does not really render the application, mostly a white screen. This happens the same way in firefox and chrome.

Oh, wait, now that I look at it, datomic is started as datomic:mem. I had datomic:free running. That might be the problem.

@anmonteiro: The docstring suggests server side control, which I have not, and the output of om/process-roots seems to strip the query parameters, which are what the xhr url is constructed from so that doesn't seem to simplify this. Thanks for trying though.

It was the ";; ugh horrible hack" line of the snippet that was my complaint, maybe I should have pointed that out.

to get params, which are later used with (format url params) which does string replacement to build the URL.

@nano: what does an example query of those look like?

It's Swedish televisions Apple TV API that I'm accessing to build a app for my Samsung TV.

@nano: no I meant a typical Om Next query

ah, child component query, '[({:category ?item} {:section ?section :view ?view})]), and what the reconciler send function gets: {:remote [{:child [({:category [:item :short :title :url :image]} {:section "samhalleochfakta", :view "alphabetical"})]}]}

needless to say, i have a similar nasty hack in my update-route, where I smash in the current child query parameters in [:children 0 :children 0] of the query.ast.

@nano: I can confirm that process root does strip out query's parameters ? I was working on a simulated server on frontend and I experienced the same thing.

@nando @nxqd process-roots Bug confirmation +1

Huh, it's a bug? Isn't it suppose to work like that then?

So you're saying process-roots stripping away parameters is the intended behaviour?

there's already a PR open for that https://github.com/omcljs/om/pull/548

@anmonteiro: Awesome!

Is there currently a way to force re-render of the root component? Something that will be possible with touch! when #485 is closed. But I need it now

have you tried a no-op mutation

transact something that does nothing and pass the keys to re-render

there might be better hooks you can tap into

yes but that I can’t specify enough reads so that the root component gets re-rendered

I also tried to update a unused query param - this works one time but not a second time

set-state! on root component only issues local reads but not remote ones

To be more specific: a noop mutate works but only when the read results in a remote read and possibly only when data comes back from the server.

@akiel: you can always add-root! again..

@akiel: but before that, try queueing your component for re-render and then scheduling a render

e.g. (om.next.protocols/queue! reconciler [component]) (om.next/schedule-render! reconciler))

it might not go remote, though

@anmonteiro: this works but does not read from remotes

ha

queue-sends!?

I'd say gather-sends -> queue-sends -> schedule-sends

yes

you're basically almost implementing touch! yourself

thats what transact is doing

transact!, set-query!, etc

Where can I find documentation how to build and test om? I have a touch! now but I can’t figure out how to build.

http://stackoverflow.com/questions/34477057/including-om-next-source/34560379#34560379

thanks

@anmonteiro: and building a jar? I only see building devcards.

@akiel: lein jar should do it, no?

@anmonteiro: I’m an idiot - I thought about cljsbuild but a CLJS lib is not compiled.

yes lein jar and lein install works

Hi, I have some problems with getting the data normalized automatically by the reconciler. I have an example here https://gist.github.com/snichme/bad850bdbd33f6cd3a81 and if I use the code exactly like this it works, it normalizes the code after the Card component but if I remove the query part on line 56 it doesn’t normalize the data anymore. Why doesn’t it do that? The query above which is for an identity also uses the Card query. The result is that no data is found for my ident query and it renders blank. Any ideas anyone?

@dnolen I re-watched the conj talk last night, and you mentioned that you had turned away from visible event models. Can you expand on that at all, or can you point at a thing does? I’m assuming it’s just issues with tracing the cause of change?

@snichme: from what little i know I would say that if you remove the query part in line 56 the reconciler doesn’t know that the :cards key in your initial data contains a card.