Clojurians Log v2

do we need a share button? so we could compare different projects ? 🙂

hm, probably i could just add a button that will copy to the clipboard in text format, and anyone could share it here 🙂 if they want

something like this, format and copy is welcomed 😉

stats for my re-frame project by re-frisk db: 75 | fx: 198 | cofx: 4 | event: 727 | sub: 402 (86)

75 keys in app-db. and 86 active subscriptions from 402 at the moment

Hey folks. I’m using vis.js timeline with re-frame [1]. The timeline has ‘datasets’ that hold items which are displayed in the timeline [2]. The issue is that I need to be able to manipulate these datasets (which are js objects) in different parts of my app. I’m not sure how to model this with re-frame. I suppose storing the dataset objects in the app-db is not a good idea - it looks awkward because the I think db won’t change even if the object does, and it’s not serializable. So far, I did the following: - I’m storing the datasets in atoms declared in some namespace - For manipulating the datasets (add items to it, for example), I created a coeffect that knows about that atom. - For reading the datasets, I’m not sure what I can do. I’ll probably create some functions that access the atom. This works and it’s testable (I reset the atoms in each test setup), but I’m wondering if there’s a better way of doing this. [1]: https://visjs.github.io/vis-timeline/docs/timeline/ [2]: https://visjs.github.io/vis-data/data/dataset.html

If you have to reset an atom to make it store the change, then you can store it in app-db and it will work fine. If you can mutate a dataset object, then you don't really need an atom. You could potentially still store it in app-db if you update and extract the data only via a small set of functions that you control - then you could wrap the mutable data in an immutable map that has an extra :version key or something like that that's changed each time you mutate the data.

Great, I’m applying your suggestions and it does look better. Thanks.

when I've needed to source external data into re-frame, I've avoided putting it in appdb: see https://widdindustries.com/clojurescript-firebase-simple/ . is there an argument for doing so?

in lieu of the machinery that firebase provides out of the box, I think re-frame's app-db is most useful when used as a place to store external data

but that wasn't what my question was about 🙂

By "The CPU problem", I'm assuming you a referring to the process of having more than 16ms of computation to do. So you do some computation, and then you want to hand back control to the browser, and then pick up where you left off and continuing on for a while longer, and then hand back control, etc, multiple rounds?

And so you are wondering about doing that kind of iterative process (round after round) in a subscription handler? Rather than via an event handler?

right.

or even just splitting up the computation of the subscription handlers. if I change some data in the app-db, and it triggers 5 subs that each take 4ms, I've overrun my budget

Hmm. I'll have to dwell on that. No clean way jumps out to me.