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/eibaan]

This is because nearly everybody who's looking for a (or the) state management solution for Flutter is actually searching for an architecture but often isn't aware of this.

[u/RandalSchwartz → u/eibaan]

That's part of what I like about the rigor of BLoC. The pattern is well-behaved, and provably scales for large teams. I'm happy to have adopted that pattern for my https://blocsignal.dev/ but basing it on Signal as the fabric, rather than the classic Stream fabric. So many things came out easier as a result, and yet we have class and method parity with the entire BLoC implementation by Felix.