Fork me on GitHub

Hi all, pretty new to I’ve been reading the docs, and while there are docs for remote integration and datascript integration, there is nothing about remote integration while using datascript to manage app state. I’m currently stuck at dealing with the reconciler’s :send function, and the callback om provides to merge the novelty back into state. I understand I’ll have to do something to make the reconciler know how to deal with datascript (assuming I’ll have to provide some sort of function to change the way merge! works), but at this point, I’ve run out of docs. Can anyone give me a hint? Thanks in advance!


@levitanong: I've been battleing to learn for 5 months. I would personally take one bite at a time and wait with datascript. To get you started with :send just realize how the function returns a function. So for

(defn transit-post [url]
  (fn [{:keys [remote]} cb]
    (.send XhrIo url
           (fn [e]
             (this-as this
               (cb (t/read (omt/reader) (.getResponseText this)))))
           "POST" (t/write (omt/writer) remote)
           #js {"Content-Type" "application/transit+json"})))
you could use it directly with
((transit-post "") {:data {:params {:a 1 :b 2}}} prn)
Given that your backend is accepting and responding with transit. Also note that ring-transit is broken and use rather this code to wrap the transit POST in the backend Just pass the function to the reconciler as is: :send (transit-post "localhosturl") and in read and mutate functions use :remote true whenever you want to communicate with the backend.


@hlolli: Yeah, letting go of datascript for the moment seems like a wise choice. 🙂 I am aware that :send returns a function (Your example very succinctly describes what it does) but I’m still unclear on the nature of the callback that the om reconciler (in your example, it’s prn, if I understand correctly) passes to :send. Does the reconciler just pass merge! with itself as an argument? Oh, I did not realize ring-transit is broken! I’ve been using this, thank you for pointing this out! I will read this in detail. And thank you for your response. 🙂


haven't worked on it in a while, might be out-dated


but basically merge-tree is what you need to implement


My word, this may be exactly what I needed. Thanks, @danielstockton! This should be in the om docs or something 😄


@levitanong: Yes, the reconciler will inject some merge from the response into the app-state. There's also :merge keyword in reconciler that you could use to control how it is merged into the app-state.


@hlolli: Ah, now I see. Thank you, and @danielstockton, for helping out 😄 Your answers have been a big help!


@dnolen: I managed to track down what’s happening under advanced compilation wrt. the elision of static methods in components


this basically emits the @nocollapse JSDoc but it’s overriding 2 functions in cljs.core


not sure if it’s desirable to do that


@anmonteiro: thanks, looks like a fine solution to me for now, patch welcome


also not sure if it’s desirable to have some fix for this in CLJS itself


not desirable to have anything for this in CLJS itself


it’s clearly a real Closure issue if it’s a problem for static ES6 methods


Yeah, the Closure issues weren’t closed, so I suspect an upstream fix will be made


however the earliest issue for this case dates back to 2014


right, but people are only just starting to push ES6 stuff (via Closure) so I suspect a matter of time


@dnolen: probably, yeah. I’ve subscribed to all the related issues in the closure repo, so I’ll be notified of an upstream fix if that’s the case


in anycase, @nocollapse trick fine for Om for now


last thing: need an issue in Om for this, or PR suffices?


hrm, I’ll open an issue for future reference and link to those Closure issues


@anmonteiro: right that’s a good idea, thanks!


@dnolen: just got around to submitting the PR. also included some other changes, such as fixes for advanced compilation of the devcards examples and removed code in next.cljs that worked around the elision of static methods


also cc/ @wilkerlucio with this commit, you stop needing the workaround for advanced compilation that we were discussing the other day