Clojurians Log v2

There's an old issue with quite a lengthy discussion: https://github.com/day8/re-frame/issues/137 But what's the purpose of having multiple DBs in your case?

Thank you. In my case, I am interested in using UIX/reframe to coordinate a set of React components and then mount multiple instances. I expect the state of each of those to be independent but they were bleeding into one another. Per Claude, I ended up adding an id in the DB for each DB-instance. That works but I thought there might be a simpler way.

FYI: this is the WIP https://zachcp.github.io/livemol/

each editor/molecule viz gets its own state.

( its coming along nicely but needs some CSS love )

Cool project! The main value-add of re-frame, at least the way I see it, is its central storage. It makes a lot of things trivial - global observability, automatic total state preservation, comprehensive undo-redo (well, not trivial, but much simpler than it would be otherwise), etc. If you don't really need any of that and can't think of any other reason why a single global storage could be beneficial to your app, then maybe going with bare Reagent would make more sense? You have something that resembles subscriptions - reactions and cursors (re-frame's subscriptions are actually just reactions). You don't have declarative events, but if you don't need observability then it should be fine to use regular functions. And if Reagent would indeed be more suitable, then maybe UIx will also work just fine without any other library. But I'm much less familiar with UIx and any patterns for state management there.

@p-himik I totally agree. Except in my case it wasn't super clear how to pass the data up and down the render chain. re-frame provides a nice conceptual model for me. But now that its written and works I think I could potentially move to refactor in the reagent direction.

Suppose you have two main components, A and B, that are completely independent in every regard. A can create its own global-for-A state, or you can create a global (def a-state (r/atom {...})) for it and pass it to A as an un-deref'ed ratom when you create the corresponding Hiccup. Same for B. Both A and B would then create sub-states using reactions that are appropriate for every sub-component. The deeper into the render chain you go, the deeper the nesting of reactions gets - the same thing is common with with subscriptions, only you don't create them dynamically.

In my case I need A (code editor) to mutate the data for B. I guess I could put both A and B at the top?

That would be simpler.....

Ah, I thought you needed multiple editors with an associated visual component for each, where every editor+visuals pair is completely independent from any other such pair. So in the case that I was describing A and B are each such a pair.

yeah. the idea is you can live edit and the VIZ will update. But the state gets tangly. (its not so bad but it was easier to design when I can just push/pull from a global - e.g. re-frame db)

Yeah, I'd definitely use a single app-db for that and not seek any way to separate it - it would only make things harder, not easier. If you don't need to have multiple editors, just store all editor-related data under e.g. an :editor key in app-db and all the visuals-related data under :visuals, and so on. If you have data that's common in nature and isn't specific to any component, it would make sense to store it under its own key.

Thanks for the heads up. I might explore the reagent option now that I've got a working project. I do like Reagent's simplicity. Note: UIX solved the "it just works" problem which made getting started on a project straightforward.