Fork me on GitHub
Daniel Hines17:01:57

I’m writing a multi window electron application. One of my goals is tight consistency and robust debugging, so I’d like to drive all application state of all windows from a central state atom, and I’m looking for a DB solution I can do this with. One thing I’m looking for in debugging is the ability to time-travel - pop a transaction off the stack and/or replay them. The DS docs say this is doable, but one needs to write it oneself. Are there any examples of this sort of thing?


Hey @d4hines. I think you get most of what you need from the fact that a datascript database is just a (immutable and persistent) value, and a conn is just an atom for a series of such values. If you create a reference to a past db state, you can simply reset it into the atom. However, keep in mind that if you're using Posh, it depends on all changes happening as transactions for its update machinery to work, so you'd probably having problems with this approach and would have to fill some gaps.

Daniel Hines23:01:25

Ok. Because datascript doesn't do history like datomic does, I wasn't sure whether it was peristant in the same way. But since it is, that sounds easy enough. My next question is how much I can store in it. Normally high frequency events, such as the location of a window as you move it across the screen (hundreds of events a second) get debounced - but I need to coordinate such events with multiple other windows (when one window enters the field of another, do stuff). I'd like to run these events through a logic engine of some sort, then add the results to datascript and distribute. How insane is it to hold onto all of those events? I haven't done the calculations to figure out exact numbers, but it sounds far-flung.