Fork me on GitHub
#om
<
2016-07-22
>
levitanong03:07:29

Hi all, pretty new to om.next. 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!

hlolli08:07:19

@levitanong: I've been battleing to learn om.next 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 https://github.com/anmonteiro/talks/blob/master/2016-berlin-meetup/src/clj/berlin_meetup/middleware.clj 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.

levitanong08:07:07

@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. 🙂

danielstockton08:07:12

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

danielstockton08:07:34

but basically merge-tree is what you need to implement

levitanong08:07:31

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

hlolli08:07:29

@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.

levitanong08:07:14

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

anmonteiro14:07:44

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

anmonteiro14:07:57

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

anmonteiro14:07:11

not sure if it’s desirable to do that

dnolen14:07:20

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

anmonteiro14:07:30

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

dnolen14:07:46

not desirable to have anything for this in CLJS itself

dnolen14:07:59

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

anmonteiro14:07:26

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

anmonteiro14:07:37

however the earliest issue for this case dates back to 2014

dnolen14:07:03

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

anmonteiro14:07:26

@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

dnolen14:07:49

in anycase, @nocollapse trick fine for Om for now

anmonteiro14:07:51

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

anmonteiro14:07:07

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

dnolen14:07:04

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

anmonteiro16:07:17

@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

anmonteiro16:07:54

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