transit

scaturr 2022-12-16T22:49:40.306689Z

Perhaps the wrong channel to ask this, but I am having an issue using cljs-ajax + muuntaja on the server. I am leveraging cljs-ajax via re-frameโ€™s http-xhrio. Muuntaja generates a response that looks like this:

(def response
    "[\"^ \",\"~:characters/by-id\",[\"^ \",\"~uf0d87749-6f2d-43c2-b647-faa85be222f0\",[\"^ \",\"~:id\",\"~uf0d87749-6f2d-43c2-b647-faa85be222f0\",\"~:backstory\",\"\",\"~:color\",\"#737530\",\"~:portrait\",[\"^ \",\"~:gender\",\"male\",\"~:path\",\"male-trader.png\",\"~:name\",\"Male Trader\"],\"~:state\",\"new\",\"^8\",\"Aderlard the Stubborn\",\"~:voice\",[\"^ \",\"^6\",\"male\",\"^2\",\"brian\",\"~:label\",\"Male 2\",\"~:samples\",2]]],\"~:characters/all-ids\",[\"~uf0d87749-6f2d-43c2-b647-faa85be222f0\"],\"~:story\",[\"^ \",\"~:title\",null]]")
And I can decode it just fine at the repl using this:
(transit/read (transit/reader :json) response)
However, cljx-ajax is giving me a parse error. Is anyone able to point me in the right direction?

scaturr 2022-12-16T22:50:32.898839Z

My re-frame event handler looks like this:

(reg-event-fx
 ::create-session
 (fn [cofx _]
   {:http-xhrio {:method          :post
                 :params          (select-keys (:db cofx) [:characters/by-id :characters/all-ids :story])
                 :uri             ""
                 :format          (ajax/transit-request-format)
                 :response-format (ajax/transit-response-format)
                 :on-success      [::start-session]
                 :on-failure      [::session-error]}}))

scaturr 2022-12-17T14:37:09.193039Z

Turns out the underlying goog.net.Xhrio instance is stripping characters when calling .getResponseText

scaturr 2022-12-17T14:37:15.418159Z

resulting in the format that triggers that error

p-himik 2022-12-17T14:39:11.952459Z

That is extremely weird. I myself use :http-xhrio with Transit and I've never seen anything like it.

p-himik 2022-12-17T14:39:36.193989Z

If you can create a public MRE, I'd be curious to take a look.

scaturr 2022-12-17T14:40:33.980079Z

Do these request/response headers look correct?

scaturr 2022-12-17T14:41:50.787259Z

Actually facepalm , I am noticing the response coming back as this:

[:characters/by-id {#uuid "f0d87749-6f2d-43c2-b647-faa85be222f0" {:id #uuid "f0d87749-6f2d-43c2-b647-faa85be222f0", :backstory "", :color "#737530", :portrait {:gender "male", :path "male-trader.png", :name "Male Trader"}, :state "new", :name "Aderlard the Stubborn", :voice {:gender "male", :id "brian", :label "Male 2", :samples 2}}}][:characters/all-ids [#uuid "f0d87749-6f2d-43c2-b647-faa85be222f0"]][:story {:title nil}][:id #uuid "5b9d0c7d-d85d-4a13-996e-2c13bac671eb"]

scaturr 2022-12-17T14:41:55.186389Z

I bet my server is doing something weird

scaturr 2022-12-17T14:42:12.077469Z

or rather I am doing something incorrectly

scaturr 2022-12-17T14:51:58.422949Z

I got it to work. Thank you. I think I expected muuntaja to format it correctly by virtue of setting the content-type header in my route handler

scaturr 2022-12-17T14:52:17.293799Z

If I use transit/write directly, it sends the correct response format

scaturr 2022-12-17T15:09:17.111109Z

Thanks again for the help. This ended up being a classic case of ordering ring middleware incorrectly. If it is useful to anyone else, the following order makes it work a treat (provided you are using similar middleware):

(defn ring-handler
  "Create the main ring handler. Uses site-defaults but disables
   the anti-forgery middleware."
  [routes]
  (-> routes
      (m/wrap-params)
      (m/wrap-format options)
      (ring.cors/wrap-cors :access-control-allow-origin  [#".*"]
                           :access-control-allow-methods [:get :post])
      (ring.defaults/wrap-defaults defaults)))

๐Ÿ‘ 1
p-himik 2022-12-17T01:57:42.404669Z

Yeah, I'd ask it in #clojurescript since it's about cljs-ajax and not about Transit itself. But from the error, it seems that cljs-ajax doesn't get what Muuntaja sends - instead, it gets "[:characters/by-id ...]" for some reason. I'd double check what gets sent over the wire in the Network tab of the DevTools panel. If it's proper Transit, then I'd debug cljs-ajax itself. If it's improper data, then something's probably wrong on the backend and maybe with the headers that cljs-ajax sends.

scaturr 2022-12-17T02:46:41.640859Z

Awesome. Thank you ๐Ÿ™‡