Is it considered bad to use component local state in re-frame? Should everything go into the app-db?

The use case I'm thinking about is a collapsible panel.

My (limited) experience has been that every time I think I’ve got a valid use case for local component state, I think of something I want to do with that data outside the local component.

Though that’s also led to the experience of finding it remarkably easy to refactor from local state to app-db state.

Makes sense. If others have thoughts on that topic, I would be curious to hear more, too.

I like managing state through events, so it feels like the intended way with re-frame is to use the app-db. However, it ends up a kitchen-sink 🙂

I think I did have a few use cases where local state made sense, like if you click on an “info” icon and it pops open a small text snippet in-line with the field it’s describing. Purely visual effect, no real mutable state to manage other than visibility on/off, so I went ahead and just used a local.

The way I manage the “exploding app-db” problem is by breaking it up into what I’ll call sub-db’s (for want of a better term). Like in app-db, I’ve got a key called :user-profile-editor that holds the data for editing a user profile form, any validation errors, and anything else I need for editing.

To edit a profile, I copy the data out of a different area of the app-db, and then when we’re done editing, copy it back. That way it’s easy to discard changes if the user clicks “Cancel”

But as far as the main app-db is concerned, all of that data is just an opaque block under the :user-profile-editor key, and all the code that manipulates that block is off in its own namespace.

Thank you for your input @manutter51

I'll try out that pattern.

@vinai as a general rule, any state that can go in app-db should go in app-db. That's the enduring goal we should all be pursuing. Having said that, there are certainly cases, involving reusable components, where it makes sense for view-only-related state to be local.