@darwin: this looks really interesting

Unfortunately I’m pretty heavily laden with work at the moment so I haven’t had the time to give it the attention it deserves yet

Probably one to review late at night with a glass of red wine

Does anyone know why the re-frame app-db is not defonce? (I am looking to maintain state during development with figwheel, whilst not having to use localStorage, as the todomvc example does.)

@owenrh: I would say it was just overlooked, the devs weren’t probably optimising for figwheel’s reloadability

but it should be no big deal in this case, because you should not be touching re-frame source files under normal circumstances

so their defs shouldn’t be redefined during normal development session

@tel don't know re-frame well enough to give you a definitive answer but it seems to me that re frame is fundamentally oriented towards having 1 db and 1 events timeline

@val_waeselynck @tel: I’m just working on a version which will allow multiple instances of re-frame, with arbitrary mechanisms of processing and applying events: https://github.com/Day8/re-frame/pull/107

to answer @tel, under this new re-frame, you will have to provide reducing function, which will be responsible for accumulation and applying results to your app-db, here is an example of such function: https://github.com/darwin/re-frame/blob/transducers/src/re_frame/scaffold.cljs#L138-L146

it re-implents default re-frame behaviour of reset!-ing each new-state on app-db atom

but it could be doing something else, for example coalescing some app-db updates, or skipping some states or using some other storage than atom, or writing to channel or sending stuff over network... you name it

@darwin: love where this is going.

I believe having a library that is purely dedicated to sophisticated state management could make re-frame ahead of every thing else.

@darwin: thanks. I worked it out in the end. There is an :initialise-db event being dispatched which overwrites the app-db contents. I disabled the localStorage code and updated the :initialise-db handler to merge in the existing db contents and now I get the behaviour I was expecting.

Interesting. With multiple flows your core app-db becomes a map of ratoms perhaps?