This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-07-12
Channels
- # announcements (2)
- # beginners (36)
- # boot (6)
- # calva (2)
- # cider (18)
- # clj-kondo (1)
- # cljdoc (2)
- # cljs-dev (2)
- # clojure (130)
- # clojure-boston (1)
- # clojure-brasil (3)
- # clojure-czech (1)
- # clojure-europe (11)
- # clojure-italy (4)
- # clojure-losangeles (37)
- # clojure-nl (9)
- # clojure-seattle (2)
- # clojure-sweden (8)
- # clojure-uk (23)
- # clojurescript (13)
- # core-async (21)
- # cursive (13)
- # data-science (6)
- # datomic (12)
- # emacs (36)
- # figwheel-main (9)
- # fulcro (76)
- # juxt (2)
- # keechma (18)
- # leiningen (4)
- # off-topic (13)
- # pedestal (37)
- # re-frame (21)
- # reitit (2)
- # shadow-cljs (78)
- # spacemacs (23)
- # sql (13)
- # tools-deps (25)
- # uncomplicate (4)
- # unrepl (1)
- # vim (27)
@joshkh that would mean your event handling code and rerender is taking a very long time. So long, in fact, that Chrome thinks it will lead to a bad user experience.
You are "locking up" the single thread of control and making the Chrome app unresponsive. You can, of course, shrug your sholders and ignore it, but Chrome is worried for a reason. Its not ideal.
On the other hand, I'm assuming this is the development build, so the production build will likely be faster.
But probably not THAT much faster that this issue goes away.
Something is probably wrong if the event handling and rerender is taking half a second (although you are not specific and say only <N>ms, so I'm not sure what N really is)
That's a direct copy and paste from Chrome. It's giving me <N>ms
! Is it possible that the warning is related to figwheel and not re-frame?
I transitioned to deps.edn
and figwheel-main
a while back and found the results to be a little more painful than what comes with re-frame's lein template (which works like a charm). For example, I had to add quite a few hooks and re-render methods that I didn't need before.
@joshkh dev builds can add overheads per action. They aren’t that large, but big enough to trigger those warnings. Try advanced optimizations 😉
If doesn’t help – I’d measure state recalculation+re-render time and based on that maybe invest more time into fine-grained subscriptions based on signals, since they reduce the amount of re-render.
started running into this no handler registered for effect 'event'. Ignoring.
Opened https://github.com/Day8/re-frame/issues/536
Just checking because I didn’t see it shown in the issue, but there is a registered effect called event somewhere in your project?
@oconn nope none of that. There’s an interceptor that alters a specific event in coeffects, but it doesn’t help if I turn it off.
@ognivo re-frame injects two interceptors into the interceptor chain when you use reg-event-db
or reg-event-fx
. The second is do-fx
which takes the effects map and triggers each one when after
is called. My guess - you’re seeing that error because :event
is getting mapped in there.
If you are seeing it across multiple triggered events, my first guess would be a custom interceptor is causing the issue
I’ve just replaced all my interceptor functions with identity
, cleared compiler and browser caches, tried both dev and production build. Doesn’t help.
This is a recent thing, so I guess I’ll try a rollback and dissect tomorrow
That does seem odd. Are you seeing this across multiple triggered events? Another thing you could try is placing an interceptor at the front of an interceptor chain of an event that is effected - that logs the co-effects in it’s after function. Are you using re-frame-10x
?
Yes, I like this idea, I should log it this way, thanks! I am. Turning it off doesn’t help though) Or you’re suggesting its tracing abilities?
Uh oh, yeah, my fault. I wasn’t supposed to return back the whole context, right? Yes, if a function returns {:db db}
instead of ctx
– it’s all good.
@oconn thanks a lot, mate! Wish you a very nice weekend 🙂 🍺❤️