I used the fancy ^:flush-dom fanciness per https://github.com/Day8/re-frame/wiki/Solve-the-CPU-hog-problem#forcing-a-one-off-render at https://fasiha.github.io/re-simple-term/resources/public/index.html — if you click "Submit" twice, the 2nd time you'll hit the CPU hog, which takes 300~600 milliseconds to complete. My question is, in Chrome & Firefox, I see a "Busy…" div below the textarea for the interval of the CPU hog, but in Safari I don't

I've confirmed the Safari issue with someone else. Any idea what might be happening with Safari?

(This is a super-simple app I put together for @lspector who was asking for a way to web-ify their Clojure terminal app on #C03S1L9DN)

@fasiha: looks like there is a difference in event loop handling

Patch welcome 🙂

Is there a way to get re-frame and reagent-forms to work together. I know they are not meant for each other but I am building a quick prototype and they both seem to be perfect picks (in isolation).

@fasiha: I don't have access to safari.

But this will be a timing issue. The job of ^:flush-dom is to delay the CPU hog until such time as the browser has been given a chance to redraw. So if that isn't happening on Safari, then the delay is not long enough.

Are you running with [reagent "0.6.0-alpha2"] ?

I think I found a way using reagent/track.

@fasiha: the key code in re-frame is here: https://github.com/Day8/re-frame/blob/master/src/re_frame/router.cljs#L66-L68

You can try changing that to be a sledge hammer like:

(def later-fns
  {:flush-dom (fn [f]  (js/setTimeout f 20))   ;; <--- CHANGE THIS LINE TO run in 20ms 
   :yield     goog.async.nextTick}) 

BTW, I didn't really understand your test, so I'm taking your word it doesn't work currently. Without seeing the code, I'm hoping your test is accurate??

@mikethompson: I could definitely use someone else looking at the code! https://github.com/fasiha/re-simple-term/blob/gh-pages/src/cljs/re_simple_term/handlers.cljs#L24-L30 that handler is fired when user clicks "Submit". It then does (dispatch ^:flush-dom [:process-input]) which is a CPU hog whose code is at https://github.com/fasiha/re-simple-term/blob/gh-pages/src/cljc/awesome_app/core.cljc#L26-L30

But of course as the the Wiki article cogently describes, the DOM is repainted before that dispatch is kicked off, so it renders a div saying "Busy…"

For me it works in Chrome & Firefox, but not Safari—safari just doesn't display the "Busy…" div. For my collaborator, it works only in Chrome—Safari doesn't display "Busy…" and neither does Firefox for them—Firefox just freezes with the button pushed till the CPU hog finishes hogging

We probably don't absolutely need this—hopeful we can chunk the work into nominally-RAF-sized pieces.

I was just wondering if there was a straightforward fix. The 20ms timeout vs what you already have would be not just (a little) wasteful but also less future-proof?

If so I'll try harder to avoid CPU hug

@mikethompson: just saw your question, yes I'm running 0.6.0-alpha2 reagent

@fasiha: I'm not suggesting that the 20ms delay is a fix, rather that it is an experiment