This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aws (14)
- # beginners (111)
- # boot (12)
- # cider (1)
- # cljsrn (7)
- # clojure (65)
- # clojure-dusseldorf (1)
- # clojure-germany (7)
- # clojure-greece (10)
- # clojure-italy (13)
- # clojure-poland (7)
- # clojure-russia (7)
- # clojure-spec (53)
- # clojure-uk (29)
- # clojurescript (27)
- # community-development (9)
- # cursive (2)
- # data-science (1)
- # datomic (17)
- # emacs (16)
- # events (6)
- # fulcro (155)
- # graphql (8)
- # instaparse (1)
- # leiningen (30)
- # lumo (29)
- # om-next (3)
- # other-languages (46)
- # pedestal (11)
- # portkey (7)
- # re-frame (13)
- # reagent (6)
- # ring (8)
- # rum (1)
- # shadow-cljs (75)
- # sql (1)
- # timbre (3)
- # unrepl (128)
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 🙂
Is it possible in re-frame-trace to get aggregates of how much time spent in certain subs?
@U04V15CAJ remember also that we're in the browser. Any one timing is notoriously unreliable because so much is going on out of your control (GC, etc). You kinda have to do an action 20 times and then take the lowest value to get a reasonable figure.
BTW, remember also that you are timing a dev build, which will be quite a bit worse than prod builds.
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
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
app-db looks like
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. 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
(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?