andre 2021-03-30T07:39:10.052900Z

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

andre 2021-03-30T07:40:45.054100Z

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

andre 2021-03-30T07:52:48.054600Z

andre 2021-03-30T07:53:47.055500Z

something like this, format and copy is welcomed 😉

andre 2021-03-30T10:21:45.057900Z

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

andre 2021-03-30T10:22:51.058500Z

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]: [2]:

p-himik 2021-03-30T13:08:46.059200Z

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 . is there an argument for doing so?

lilactown 2021-03-30T21:23:54.060200Z

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

lilactown 2021-03-30T21:24:08.060400Z

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?

lilactown 2021-03-30T21:46:43.061200Z


lilactown 2021-03-30T21:48:22.061400Z

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.