This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-07-22
Channels
- # admin-announcements (1)
- # aws-lambda (1)
- # beginners (38)
- # boot (48)
- # cider (11)
- # clara (4)
- # cljs-dev (61)
- # cljsrn (9)
- # clojure (68)
- # clojure-austin (3)
- # clojure-greece (9)
- # clojure-mexico (6)
- # clojure-russia (40)
- # clojure-spec (165)
- # clojure-uk (134)
- # clojurescript (37)
- # cursive (5)
- # datomic (25)
- # defnpodcast (2)
- # hoplon (1)
- # jobs (1)
- # juxt (1)
- # lein-figwheel (3)
- # leiningen (4)
- # mount (14)
- # off-topic (8)
- # om (29)
- # onyx (9)
- # protorepl (4)
- # quil (1)
- # re-frame (56)
- # reagent (3)
- # rethinkdb (1)
- # spacemacs (4)
- # specter (12)
- # test-check (2)
- # testing (1)
- # vim (12)
- # yada (4)
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!
@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.@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. 🙂
@levitanong: i made a starter project with datascript https://github.com/danielstockton/om-next-frontend/blob/master/src/om_next_frontend/core.cljs#L98
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
I put together a hack that fixes the issue: https://github.com/anmonteiro/om/commit/b8cbf8c86ff86996ac3214427415c1cc36cac129
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
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
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