Flutter state management: quit bikeshedding
Saturday, 1st of August, 2020 by Eric Windmill
The thesis statement of this post is simple: Quit wasting your time debating state management libraries.
The state of state management in Flutter
- "Which state management library do you recommend?"
- "Should I use Bloc or Provider on my new project?"
Or, the even more dubious:
- "Should I migrate my project to The New Hot Library?"
First off, of course, there is no problem with asking the questions. It's the answers and hot takes I see on Twitter that rub my the wrong the way.
The answer to that last question, from anyone worth their salt, would be something like "What problems are you running into now with your current solution?". Which, by the way, is a way to lead you to the real answer: No. You absolutely should not.
The non-trivial piece of this conversation
In a way, this isn't endless framework debate isn't all bad. It's possibly what's responsible for the creation of Angular or React or Vue in the first place. It (seemingly) drives folks to make something better than the currently available tools. Making great tools will never end in the programming world, and that's worth celebrating.
But, we now have Angular and React and Vue, among other frameworks to build web apps with. These are all great products with pros and cons that can help developers build good, working software for the web. Do we really need another? Well, that depends on what the real, final goal of using these libraries are.
Why do really use state management libraries?
The initial answer that may pop in your mind is "To manage state, duh." And this answer is correct. State management is hard. And any library that simplifies this problem and allows us to make software that is more reliable is a Good Thing.
But, I'd argue that this isn't the end goal. Making state management easier is just a means to the true end: Writing good, working software.
That's it. That's our goal every time we sit down to write code.
And, how do we measure good, working software? It isn't by clean code. It isn't by taking a shotgun full of design patterns and blasting it into a repository. It's by bringing value to the end user.
Let me condense this into a sentence:
The ultimate goal of a programmer is to bring value to the end user.
Full stop. That's all you should care about.
What do your users care about?
I'm going to take my current job as an example. I work on two applications that help certain businesses (marijuana despensaries) manage their sales, track their business, and stay compliant with state and federal laws.
Every day, we get some number of feature requests or bug reports, which eventually makes it's way to the engineers, who write code, test code, and eventually ship code. These feature requests always (100% of the time) are features that the customer wants to make their lives easier.
Do you know what feature request I've never, ever seen, at any of my jobs? "Hey, do you think you could re-write your app to use Provider instead of blocks?" That will never happen.
Our web app is written in Ruby (version 2.something) and Ember.js. In other words, old technologies. But you know what? The application works. And that's all that matters. The end user does not care, so long as we deliver Good, Working Software.
Please, quit bike shedding
As soon as we start bike shedding about using this library or that to solve problems that largely do not matter to the end user, we are doing everyone a disservice (including ourselves).
When we debate the validity of blocs vs inherited widgets vs provider, we're missing the point.
Just as Angular, Vue and React can be used as a tool to build Good, Working software_ for the web, all these different state management libraries can be used to create Good, working Flutter apps. Period.
Not only are we focusing on a trivial matter, but we're making the Fllutter community harder to enter for beginners, and conveluting our own minds. These are both bad things for the continued progression of the Flutter ecosystem.
Hell, the point of libraries is to allow us to focus on domain problems, and stop thinking about problems that are already solved. In todays world, the statemanagement problem is rightfully solved. A day may come when it isn't solved, and when that day comes I will encourage everyone to start the debate back up. But for now, quit bike shedding and start building Good, Working Software.
- I understand that innovation is important. You should innovate, but a new pattern to inject state into widgets isn't innovation. It's keeping you from doing the real work.
- I also understand that debating and learning is fun. If that's the motivation, then by all means, continue debating and learning. I only ask that when someone asks a dubious question like "Should I use x or y", you're honest about the fact that it does not matter.
- There are great tools for Flutter application state-management that I am extremely thankful for. I have used many of them for apps at jobs that are used by thousands of businessness for mission critical work. They certainly made those jobs easier. But, I have built working software using Bloc, Provider, and even vanilla Flutter , and people are out in the world using that software today, not knowing the difference. In the end, there wasn't much of a difference in my day-to-day like while using these different options.
So, should you migrate your project from Provider to The Next Big Thing? Well, does your software work? Then no, you absolutely should not.
If you're starting a new project, what should you use? Surely that matters...
It does! Use whatever technologies make YOU the most productive. If you're dang good at using bloc, but you've never used Provider, don't sweat it! Use bloc! Who cares? Your end users certainly do not.
If you're a super productive React Native developer, then you probably don't need to learn Flutter. (Repeat forever about every programming language, framework, etc.)
Thank you for listening to my rant.