re-frame-trace looks pretty awesome - great job @daiyi and @saskia (and @danielcompton too of course) Do you think it would make sense to add a browser for subscriptions and events similar to how you can browse app-db? I experimented a bit last year with how to visualize the re-frame.registrar/kind->id->handler atom and I found it pretty useful in understanding how things worked under the hood, but I didn't get it polished or working well enough for anyone to really use. Any interest if I can figure something out that would get a decently usable browser for either of those, or is it out of scope for what you want out of the library?

happy to hear, thanks Shaun! I remember thoughts about implementing a data browser for event and subscription data as well. That would definitely be a useful addition! For now, you can print the data to the console by clicking on it in the trace details, don't know if there are any more concrete plans around it already.

@shaun-mahood The latest re-frame-trace includes a first version of a subs browser: https://clojurians.slack.com/files/U051KLSJF/F84G9MPT6/screenshot_of_google_chrome__23-11-17__10-14-14_am_.png Check which issues are in the repo and add your own issue/comment depending on what's already there 🙂

dang; re-frame-trace is nice

Is it possible in re-frame-trace to get aggregates of how much time spent in certain subs?

or in all subs? So you know if your refactor is doing any good

I'm writing an application that uses re-frame and Bokeh. Bokeh has models called ColumnDataSource - it's basically a storage for table data that can notify all connected Bokeh documents (servers, clients - no matter) about its changes. Now, that storage obviously stores data internally in a JS object. And I want to use that data in my re-frame-based UI. I've implemented a JS class that inherits ColumnDataSource and that along with notifications to the server about the table being change in the UI, it also dispatches an event that changes my app-db. But I want duplex communication, so in each instantiated new source I subscribe to the same path in app-db and use reagent.ratom.run! to monitor the subscription and to issue changes to the data source. The problem might be already obvious - such way to mirror two different sources of data will definitely result in an infinite loop of notifications. For that, I added a flag :from_re_frame - if the data in the JS source is changed with this flag, the re-frame event is not dispatched. But it's not enough! Suppose, I have a data source named ds and it has a single value NaN, and app-db looks like {:ds ##NaN}. Now, if I change the value on the backend to 0, the change will be propagated from the ds on the backend to the ds in the UI. It will then dispatch an even to change that value in the app-db. It will cause the subscription in the UI ds to update, and that would cause the data of the UI ds to be set again from 0 to 0. The problem here is that this change will also be sent to the backend. If the backend have some code like ds.value += 1 running in a loop, it will result in a havoc. A way to fix it would be to compare ds and (clj->js (:ds @app-db)) each time before I try to set the data in the UI ds. But it's not a clean solution. Is there any other way to deal with this problem? Or maybe someone can suggest some other way of synchronizing app-db and some JS class that's synchronized with a backend?

Current CLJS code looks like this: