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.