uosl 2020-08-01T10:43:30.153Z

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 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).

uosl 2020-08-01T11:03:34.153300Z

According to the API docs (, :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 and

Jose Varela 2020-08-01T20:20:27.154100Z

Love the syntax @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?