It would definitely trip up the people that rely on their app-db storing only the data that they themselves have put there. :) Not sure what the best solution is. Perhaps app-db can actually be a cursor and a ratom like full-app-db can contain it along with all the re-frame stuff?

We would definitely list it as a breaking change. I think https://github.com/matthiasn/talk-transcripts/blob/master/Hickey_Rich/MaybeNot.md?plain=1#L1211 it should be okay. Practically, we're hoping it's okay to store it all under a single key. Then it's easy if you need to dissoc it.

Yeah, maybe a cursor is the way to go

It might have performance implications though. But probably nothing serious.

I’d be curious to hear what benefits putting these into app-db would bring

Versus having them outside like now

See the pinned discussion that got started on November the 1st. tl;dr: the configuration of flows is intentionally dynamic, hence it's a part of your app's state.

Hmm. The async-flow lib I believe puts stuff in the app-db too? I can’t remember

Only if the user explicitly provides :db-path. But actually, perhaps it's not that big of a deal, to store stuff in app-db. A user still has to do something for that to happen. Either use the new flows directly or update some library that starts using flows in the newer version. It won't happen with updating just re-frame itself.

Testing this out, a problem already appeared. Many apps have an ::init event which resets the whole db. But if we store flows in app-db, that means the ::init event dissociates all the flows. The user would have to know and understand :re-frame/system to avoid this. Or we'd have to add some other implicit behavior to fix it. If app-db becomes a cursor into full-app-db, what benefit does that give us? We might as well just have two atoms, app-db and system. You have to call a second name either way, and full vs. not-full is a poor distinction. Basing re-frame's core state on a cursor sounds like asking for papercuts.

As for trace and reproducibility, maybe tools like 10x can just start tracking system the same way they do app-db. Not sure.

Mm, perhaps, yeah. And people that are interested in observing/storing the full system somehow will still be able to do it if system is a part of the public API (or if there's some function like get-full-state that returns a map of :system and :app-db).

There is something conceptually nice about a single atom, though... Maybe it would suffice to change the :db effect, so it updates a subtree rather than the whole atom.

Anyway this is starting to look big enough to be its own issue, and not a requirement for releasing flows.

I agree that a single atom is conceptually nice. But after your messages above, I can't come up with a justification that would make it worth it. It might be worth it if re-frame was a backend framework since updating two atoms that store related data is a big "don't". But it's not the case in CLJS, especially given that only one of those is a ratom and the other would be a plain atom, I assume.

Actually flows do need to be in an r/atom so you can subscribe to them.

Oh... Hmm. I could be wrong but IIRC, if a component depends on two ratoms and you update those together, it will (or can?) result in two re-renders of the component back-to-back.

Yeah I can see that behavior right now.. a live flow causes one render, but registering/clearing a flow causes two.

https://github.com/day8/re-frame/blob/9535049b167e2e81b7c5aee00ed46f9e089c393a/examples/flow/src/re_frame/flow/demo.cljs#L68

@U02J388JDEG This change did that: https://github.com/day8/re-frame/commit/f05e3d84432a28331e33c8b7db27a789a13c061a#diff-76629ad32fe598cd9688f5f226f572cf6d19d506abfabb9634c359b72b0efd7dR97

You found the mind I left behind. Fixed.

Thanks both!