re-frame 2023-12-14 | Slack Archive

hifumi12323:12:35

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-himik05:12:23

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

hifumi12305:12:17

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

hifumi12305:12:12

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

p-himik05:12:29

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.

hifumi12305:12:40

ah, now I understood your point

hifumi12305:12:41

thanks!

hifumi12305:12:08

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

hifumi12305:12:29

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-himik05:12:37

Heh, yeah.

p-himik06:12:26

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

👍 1

2023-12-14

Channels