defa 2021-03-12T08:01:20.205500Z

Hi, I’m struggling with events. I have a working solution but it doesn’t feel like “the right thing to do”. I have a long running (5-30 sec.) calculation in a coeffect injected into an effect that will write changes to the app-db. I’d like to open a progress indicator (modal dialog) while the calculation is running and I already have events for showing/hiding this indicator. As I understand, there is no way to dispatch these events in order: [:show-progress-indicator] [:perform-calculation] [:hide-progress-indicator] . My working solution is to use :dispatch-later for the first two events to order them and give the run-loop/react time to show the modal and pass the hide-event as an argument to the calculation-event so it can be dispatched when the calculation is done:

{:fx [[:dispatch-later {:ms 1 :dispatch [:show-progress-indicator]}]
        [:dispatch-later {:ms 500 :dispatch [:perform-calculation [:hide-progress-indicator]]}]]}
But this does look like an aweful hack and I think I’m missing something here. A less complicated solution is to not dispatch :hide/show-progress-indicator and modify the hide/show-flag in app-db directly in :perform-calculation.

p-himik 2021-03-12T10:55:13.205900Z

> there is no way to dispatch these events in order There is. You just call dispatch in the right order, that's it. The order is preserved.

p-himik 2021-03-12T10:57:22.206100Z

The reason for why your progress indicator might not be showing up is because re-frame doesn't give Reagent a chance to re-render the right parts. This documentation section is helpful in that regard:

defa 2021-03-12T15:13:39.206700Z

@p-himik of course you’re right these events are dispatched, as it is written in the docs. I was a bit sloppy in formulating my problem. It is not a order problem at all but exactly that what is described in the link you sent. Thanks! I guess I’ll have to try ^:flush-dom and get rid of :dispatch-later stuff.


Is it possible to listen to events? As, throw events after some events have been seen? I think async-flow might be a good solution, but I wondered if there was an alternative?


That function is quite handy :)


Thanks a lot!!


I also wrote alrightee for this:



p-himik 2021-03-12T17:12:17.207900Z

I don't remember reading about such an alternative. Unless you know you event dependency graph in advance - then perhaps can be helpful.

nenadalm 2021-03-12T17:15:26.208200Z

there's also

p-himik 2021-03-12T17:15:49.208500Z

Oh, nice, thanks!

lucian303 2021-03-12T20:58:05.208700Z

thanks @mikethompson i see why that was a bad idea and it was easily fixable

lucian303 2021-03-12T21:07:04.209900Z

i got an error like this and other similar ones. how do i know which effect it's talking about? i looked in the structure it dumps out, but it is of no help. i can't correlate it back to anything in cljs: re-frame: in ":fx" effect found {meta: null, cnt: 2, shift: 5, root: {…}, tail: Array(2), …}cljs$lang$protocol_mask$partition0$: 167666463cljs$lang$protocol_mask$partition1$: 139268cnt: 2meta: nullroot: {edit: null, arr: Array(32)}shift: 5tail: (2) [{…}, {…}]__hash: 773031096__proto__: Object which has no associated handler. Ignoring.

p-himik 2021-03-12T21:10:59.210Z

I strongly suggest using Chromium-like browser along with used in your CLJS build. It will make printed CLJS objects readable.

p-himik 2021-03-12T21:11:38.210300Z

When you see stuff like {meta: ..., root: ..., tail: ...}, it's almost certainly a CLJS collection printed as a JS object.

lucian303 2021-03-12T21:21:56.210600Z

ah, gotcha. thanks. that was not working before but it finally is working now and it makes sense