Flutter 3.0 was announced at Google IO yesterday and as can be expected from a major version jump, there were a lot of new features to dig through. A few of the big ones:
You can read more about the full release in the announcement here and if you’re someone that wants to see everything that was added, check out the release notes.
The feature that excited me the most didn’t quite make it into the announcement articles, though. Flutter 3.0* also shipped with full support for enhanced enums, meaning that your enums can now behave like mini-classes with members and methods.
Before now, enums were extremely simple — basically just lists of values. If you wanted to make them more useful, you’d need to extend them using the extension syntax. Not too difficult but not too convenient, either.
With enhanced enums, everything can be packed into the enum itself — and that’s awesome.
* Technically speaking, enhanced enums are a Dart 2.17.0 feature. That’s why they were in the Dart announcement and not the Flutter announcement…but either way…
My app, FitJo, has an enum called “Metric” that contains all the possible body-related metrics a user can track in the app. Simple, right? Not quite. Different metrics track different types of units.
To address this, I created an enum extension with a giant, ugly switch statement that let me know what type each metric was.
After migrating to the enhanced enums structure, the above monstrosity looks like this:
From 64 lines to 26!
This Stack Overflow answer provides some more details on everything that’s possible with enhanced enums so check it out if you’re interested.
In addition to reducing the overall lines of code cluttering your project, enhanced enums seem like the ideal solution for a number of different problems.
Say you have a backend with a fixed list of available endpoints. You could set up an enum for each endpoint that includes fields for the URL pathway and the API version.
If your app lets users set up social profiles, you could create an enhanced enum for all potential social platforms. Each enum would have the name of the platform (Twitter), the URL prefix that goes before the username ([https://twitter.com/])(https://twitter.com/) the icon that should be displayed (Icons.twitter), and the tooltip text that will appear when a user hovers over the icon (‘Twitter’).
For subscription apps, you may want an enum that contains all the features a subscription will unlock. Each enhanced enum would have the name of the feature, a short description, and an image asset path. When a non-paying member stumbles across your offerings page, you can cycle through the Feature.values enum list and show them what they’re missing.
Happy coding!