re-frame

hifumi123 2023-12-14T23:47:35.333819Z

What are people’s preferred method for implementing retries when an XHR from re-frame-http-fx times out? One can naively create an :on-failure event that checks (= :timeout (:failure response)) , but I dont like this since it involves manually reconstructing the event, and it seems to abstract this into a “composable” or “generic” event handler. I rarely use interceptors, so I don’t have a good intuition for them, but they seem to solve the issue of reconstructing the original http-fx event that failed. So I want to consider trying them out. Has anyone here tried using interceptors for this? and if so, do you have a simple example?

p-himik 2023-12-15T05:19:23.563819Z

> manually reconstructing the event Why? You already have the whole event vector there, just pass it along, maybe with a retry counter.

hifumi123 2023-12-15T05:56:17.424119Z

When the :on-failure event is fired, I only get the event vector of the failure handler, not the event that makes the AJAX call

hifumi123 2023-12-15T05:58:12.638059Z

e.g. suppose I (rf/dispatch [:api/get-things {:id 123 :on-success [:handle-success] :on-failure [:handle-failure]])

p-himik 2023-12-15T05:58:29.836349Z

You have the original event vector where you create the XHR effect. You can pass that vector to the :on-failure event vector. Event in event.

hifumi123 2023-12-15T05:58:40.928639Z

ah, now I understood your point

hifumi123 2023-12-15T05:58:41.933769Z

thanks!

hifumi123 2023-12-15T05:59:08.704459Z

you’re absolutely right… the event vector in my above example is already in the :api/get-things handler…

hifumi123 2023-12-15T05:59:29.884839Z

it’s tough seeing this since I almost always use trim-v on my event handlers and forget that this has utility at times 🙂

p-himik 2023-12-15T05:59:37.594099Z

Heh, yeah.

p-himik 2023-12-15T06:00:26.618329Z

You can get the original event vector as :original-event coeffect if trim-v is used.

👍 1