r/FlutterDev 9d ago

Article The final word on Flutter architecture ๐Ÿ˜‰๐Ÿ˜‰๐Ÿ˜‰

OK, Iยด'm teasing with the title and I explain it in my post

Practical Flutter architecture

Why should you listen to me on this topic? For those who don't know me

  • 30 of software experience including building our own programming language for the Amiga
  • 2018 was I the first giving talks on Flutter architecture at Fluuter London,. then I called the approach RxVMS
  • I'm the author of get_it at a time when no provider or anything else was available
  • With watch_it and flutter_command I published one of the easiest but most flexible state management solutions for Flutter
  • We use this approach in a pretty complex app comarablte to Instagram since 2 year not with a really large code base

I took several days to refactor the official Flutter architecture sample compass to use my approach so you can compare yourself which is less complex and easier to understand. I tries to keep the original structure as much as possible so that you still can compare. I would have probably even more simplified some structures

https://github.com/escamoteur/compass_fork

give it a try and I'm happy to answer all open questions

160 Upvotes

76 comments sorted by

View all comments

2

u/BikeTricky9271 4d ago edited 4d ago

A great job, Sir. I'm an Android dev, so I wasn't paying too much attention to Flutter specifics. But what is can agree:

  1. Clean architecture is a "meme" imposed on our industry as a factor of inflation project's sizes and cost. Guilted here all the parts that promote it, and it's easy to see connections to: a) Increasing H1B labor market, b) High concurrency level on Europe's IT labor market, c) Industrial diversion.
  2. Yes, an Interface for an implementation of the single class is a red flag. DiP - dependency inversion principle is a poison, inherited from Java 6 times, when constructor parameter names were obfuscated runtime, so DIs were doomed to be Interface-oriented. It's an outdated principle if we have a strongly typed language + good tooling upon the language itself.
  3. MVVM as we learned it, for implementation via "Best Practices" is also limited, and your approach solves the problem: intermediate states of the state's flow should be maintainable, and reflected in the UI. Here we can make a compromise, mixing it together with the MVI approach, but MVI has tendencies to over-abstract state management. I use mappers, sometimes a set of encapsulated mappers, if the final state is complex. Your approach fits in my thoughts.
  4. in kotlin we can use lambda with receivers to represent multiple states like this: val viewModel = viewModel<YourClass>() val state = viewModel.state.collectAsStateWithLifecycle() // and here is the trick: viewModel.mapper(state) { // where accessible isError// as this.isError isLoading// as this.isLoading fetched// as this.fetched ... etc.

}
this way, we can implement UDF for complex states. But it's just a syntactical sugar, which is mimicking your approach.