Fork me on GitHub
#re-frame
<
2017-11-13
>
caleb.macdonaldblack01:11:50

Thank you for your response. I will not do it this way if it’s not encouraged.

lovuikeng01:11:47

you may, @U3XCG2GBZ read the rational behind this not-too-uncommon request https://github.com/Day8/re-frame/issues/255

dimovich09:11:01

is there a better way of doing this without js/setTimeout?

sandbags10:11:07

@dimovich instead of using an atom could you dispatch events, the handler of which could check whether all image updates have now been complete

mikerod16:11:39

Do people find it normal to have JS/React events passed as args to event handlers?

mikerod16:11:59

e.g. (rf/dispatch [:my/event-handler click-event])

mikerod16:11:24

Or do people tend to first process the event in some other fn to get whatever data out of it

mikerod16:11:49

e.g. (rf/dispatch [:my/event-handler (extract-detail-data click-event])

mikerod16:11:36

I’m thinking the first approach is best. I am a bit leery of things that may not print well in event handler args since it is nice to see log message during dev via something like the “debug interceptor” etc

mikerod17:11:51

I think another issue that occurred to me is that perhaps it is unsafe to pass an event if it isn’t handled immediately, due to React’s reuse of the synthetic event objects

akiroz17:11:43

@mikerod I usually go with the latter and generally try to keep JS objects out of my system as much as possible.

sandbags18:11:19

Anyone else seen figwheel throw call stack size exceeded errors on reload?

mikerod18:11:14

@akiroz that has been my pattern so far

mikerod18:11:21

Good to know I’m not alone at least

mikerod21:11:51

@mikethompson thanks for the details. I tried re-looking through the docs and didn’t notice there was some relevant info already. That gives good insight and certainly answers the question

dimovich21:11:29

@sandbags thanks for the tip

sandbags21:11:49

you're welcome