I second using re-frame-10x. Our app has an event call graph at least as convoluted as yours, but I find it very manageable with 10x. Instead of trying to discern the flow of events or the contents of app-db from the code, I simply run the application and observe its behavior using 10x. To make event flows more explicit in the code, you can use https://github.com/day8/re-frame-async-flow-fx but it has a lot of overhead so it's only recommended for the initial boot of your app, after which it gets disabled. The call graph program you created sounds very cool! I think 10x could be made even more powerful if we had a visual representation of that (I know there's a similar issue for visualizing subscription graphs).
According to the API docs (https://material-ui.com/api/popover/), :open
should be a bool while you're passing a function. Just remove the #
and you should be fine.
For :on-mouse-enter
, I think (-> % .-target .-id)
should work. Although you might want to consider using React refs instead of IDs, see https://day8.github.io/re-frame/FAQs/FocusOnElement/#html-autofocus and https://github.com/reagent-project/reagent/blob/master/doc/FAQ/UsingRefs.md
Love the syntax https://github.com/day8/re-frame-async-flow-fx#flow-as-data @regen This makes event-chains easy to read. The docs say the main purpose is for sequential app-boot logic. Why isn’t this flow-syntax used for chaining events in any stage of the app’s life-cycle? My hunch is it’s too much overhead for chaining 1-2 events together, and if you have long chains you’re probably doing something wrong by structuring your flow of data that way?