Flutter ECS: Rethinking State Management for Flutter Apps

Hey everyone 👋

After years of building production Flutter apps, I kept running into the same problem: as projects grew, state management got messy.

What started as clean architecture would eventually turn into a tangled web of dependencies. Business logic leaking into widgets, tightly coupled components, and tests that were painful to maintain.

I tried everything: Provider, Riverpod, BLoC, GetX, etc. All great in their own ways, but none gave me the modularity and scalability I was looking for.

So, I built something new: Event–Component–System.

A Flutter package for radical separation of concerns:

• Components: Pure data, no logic
• Systems: Pure logic, no data
• Events: Communication without coupling

It’s not just another state management library. it’s a new way to structure your app.

If you’re curious about the reasoning and the journey behind it, checkout my detailed article here:

https://medium.com/@dr.e.rashidi/flutter-ecs-rethinking-state-management-for-flutter-apps-bd224da10881

Comments

[Mattia Maldini]

The idea to reduce events to mere "tags" is interesting and cleans up the UI, but to me even this approach fails to shake off the two original flaws of UI management in Flutter:

• Overcomplicated hierarchy. I get an headache just looking at all the classes and objects that need to be plugged in for any of this to work. To be clear, this doesn't look any worse than many other similar libraries, but it's not better either. I assume it would become clearer once I get accustomed to it, but such a fundamental functionality should be much simpler to work with.
• The state still depends on the UI, at least in its lifecycle. That's the original sin of the Flutter architecture, and your setup necessarily builds on that.

[Dr. E]

Regarding the overcomplicated hierarchy, you’re right, any library that introduces an event/system layer will inherently add some classes and wiring. The goal with this design is to make the flow of events predictable and decoupled, so once you get used to it, you’re dealing more with logical connections rather than hunting through widget trees. But yes, that initial cognitive load is unavoidable.

As for the state depending on the UI lifecycle, this is a limitation baked into Flutter itself. Any state management system in Flutter must interact with widgets at some point to trigger rebuilds. This setup tries to minimize direct coupling, but it can’t fully escape the “UI-aware state” problem without moving to a completely different architecture outside Flutter’s reactive model. The ECSManager can be used standalone though, for example in a pure dart app.

The library doesn’t fix Flutter’s fundamental constraints, but it attempts to reduce friction and make event-driven patterns more structured.

It has been a while since i published this post here, the library has evolved since, i would be happy to hear your thoughts on the new updates, especially for the devtools extention called ECS Inspector that provided real time visual debugging and dependency tracking.

Also you can read next parts of the medium article series:

• Flutter ECS: Mastering Async Operations and Complex Workflows
• Flutter ECS: Testing Strategies That Actually Work

Cheers!