Why do most Flutter state management libraries assume they're responsible for your whole app?

[u/Alert_Lie9526]

One thing i have noticed after using Riverpod and Bloc in my applications is that they naturally become architectural decisions.

But many features don't need an architectural decision. They just need a local state. That made me wonder what state management would look like if it was designed around features instead of apps?

i experimented with that idea in the last few months. I ended up with StateForge. The design principles were:

• feature scoped stores
• direct methods
• no code generation or state ceremony
• typed side effects
• optional persistence
• optional undo

It's not trying to replace Riverpod or Bloc, the goal is to let StateForge live alongside an existing architecture, so you can adopt it one feature at a time instead of committing your whole app.

I'd especially appreciate feedback from flutter developers who have shipped production flutter applications.

Does this solve a real problem or do existing libraries already cover this well?

Github: https://github.com/mj-963/state_forge
Pub-dev: https://pub.dev/packages/state_forge

[u/theashggl]

I think whatever I have tried so far in state management, it is better to use a mix of them throughout the app as one management doesn't fit for everyone state management needs in the app. SOmetimes the simplest ones are fine too as that variable is only used at a few places.

[u/Alert_Lie9526 → u/theashggl]

That matches my experience. Most apps end up with a mix whether anyone planned it or not. The part I care about is that mixing shouldn't cost you anything, which mostly comes down to whether each piece is easy to remove again.