@mikethompson Thank you. But the syntax for setInterval is

let intervalID = window.setInterval(func, delay[, param1, param2, ...]);
let intervalID = window.setInterval(code, delay);

Here's a sketch I once did (untested) ....

;; this is the effect an event handler can return to set/unset an interval
{:interval {:action :turn-on        ;; turn on or off 
            :id      123            ;; what is MY id for this interval   (not what is returned by setInterval  !!!)
            :delay 1000          ;; how many milli secs 
            :event [:do-poll 42]}}))   ;; what event to dispatch

(reg-fx :interval 
  (let [live-intervals (atom {})] 
    (fn [{:keys [action id delay event]}]
      (if (= action :turn-on) 
        (swap! live-intervals assoc id (js/setInterval #(dispatch event) delay))) 
        (do (js/clearInterval (get live-intervals id)) 
              (swap! live-intervals dissoc id))))

@cmal ^^

Thank you! @mikethompson

dissoc

thx :-)

😄

@cmal is there anything else you can see wrong/confusing with that code above ... about to enshrine it in an FAQ (this issue has come up enough times to warrant an FAQ)

But I'm too close to all this stuff ... hard for me to judge what works to people seeking answers

Any insight into how to better explain appreciated, if something occurs to you

Ok 👍

Hmm... guess I'll write a library for it then, don't want to copy that snippet in all my re-frame projects since it's kinda long and hard to read.

Any plans to add this functionality?

@mikethompson if live-intervals (atom {}) is in a defn, how to clearInterval all things in live-interval before the defn is re-applied, otherwise every time figwheel recompile the handlers, the setIntervals in this atom will not be cleared so that the setInterval will exist and cannot be traced.

@cmal maybe put the definition into a namespace which isn't getting regularly reloaded ??

@mikethompson Thanks for that!

hello friends, question: If I create a (reg-event-fx …) from a function

it seems not to be loaded into the events registrar, same for subscriptions

Is this by design?

My idea was that, since my server-side API is so consistent in its namings, I wanted to generate a bunch of CRUD calls to the server, using the new reg-event-fx with :http-xhrio effects from that http library

but it keeps complaining ‘no :event handler registered for <key>‘, whilst I see a debug statement of that code being run just before

Do these registered events become ephemeral or something, when nog being declared by a top level call to (rf/reg-event-fx ….)?

Or am i just doing something wrong?

@kah0ona I think you can reg-event-fx from a function - async-flow-fx library is doing it here: https://github.com/Day8/re-frame-async-flow-fx/blob/master/src/day8/re_frame/async_flow_fx.cljs#L206-L211

anyone any ideas how to compose re-frame-test tests together?

I have a test like this

(deftest can-search-for-product
  (run-test-async
    (test-fixtures {:timeout-event [:testing/timeout]
                    :timeout-ms 2500})
    (with-logged-in
      (let [current-route (subscribe [:navigation/current-route])
            product-search (subscribe [:ui.product-search/results])
            search-term "apple"]
        (dispatch [:navigation/jump-to-shortcut :navigation.shortcuts/product-search])
        (wait-for [:navigation/set-routing-state :testing/timeout]
          (is (= @current-route "ProductSearch"))
          (dispatch [:ui.product-search/set-query search-term])
          (wait-for [:ui.product-search.search/success :testing/timeout]
            (let [{:ui.product-search/keys [products loading-state]} @product-search
                  product (first (filter #(re-find #"apple" (:product/name %)) products))]
              (is (not (nil? product)))
              (is (every? #{:product/id :product/name :product/thumbnail :product/short_description} (keys product))))))))))

and I want to write another test that uses this as a start position

and goes on and adds the product to a basket

I think I can do it with macros but it sounds like it might be a common use case and there's an accepted way of doing this

(n.b with-logged-in is a macro there that calls login, and waits for success)

should i be able to model all my application logic through async events/effects without touching a promise library?

alternative question, does it make sense to use re-frame-async-flow-fx for events that happen at any stage of my application. as opposed to just using it for application setup?

e.g. i have async events that create models in my backend. but at certain points in my application i want to create multiple objects (some that use the uuids of objects created previously in the workflow)

hm, im having trouble explaining my issue concisely...

basically i'm finding that i need to implement what is essentially callbacks in some of my event handler functions

sometimes when i dispatch :create-model i just want it to update the app-db with the new model

but other times i want it to dispatch :create-model again using information returned in the initial :create-model response

and then other times i want to dispatch a completely different event after :create-model's response returns

i can make this work by basically dispatching :create-model with a callback-dispatch-list argument that dispatches that list after the resp returns

but i can easily see this method getting out of hand and very code-smelly