re-frame-http-fx

re-frame-http-fx copied to clipboard

I've been working out how to get incremental results, not sure if you want to support it as cljs-http might be moving from xhrio (#21). I've got an issue open there, and it can be plugged in at either level.

It's based on me reading through kennethkalmer's PR (#18) and working backwards to figure out where the change should start.

The essence of it is here:

(defn request->xhrio-options
  [{:as   request
    :keys [on-success on-failure on-progress]
    :or   {on-success      [:http-no-on-success]
           on-failure      [:http-no-on-failure]}}]
  ; wrap events in cljs-ajax callback
  (let [api (new js/goog.net.XhrIo)
        _ (when (and on-progress (fn? on-progress))
            (doto api
              (.setProgressEventsEnabled true)
              (events/listen goog.net.EventType.PROGRESS on-progress)))
        ]
    (-> request
        (assoc
          :api     api
          :handler (partial ajax-xhrio-handler
                            #(dispatch (conj on-success %))
                            #(dispatch (conj on-failure %))
                            api))
        (dissoc :on-success :on-failure :on-progress))))

You can now define an on-progress fn that does something with the partial response:

:on-progress
(fn [e]
    (let [resp-text (.getResponseText (.-currentTarget e))]
        resp-text))

Not sure if you want to support it, or should I try upstream?

The goal of re-frame-http-fx has always been to be a very thin wrapper around cljs-ajax that introduces as few new concepts of features as possible, so I would suggest trying upstream first. Appreciate the feedback and research though!

@danielcompton No problem and totally understand that, I'll see what the response is there :)... Do you mind if I leave this open here if someone's looking how they'd do it?

Sure, that’s fine.