Future Features

This chapter lists potential new features. They may be planned or even just idea phase future features. They are listed as polls in the repo discussions. Feel free to add additional ideas and requests there, and to up or down vote existing ones.

When features are being worked on, you can find them as tasks in the repo project.

Proposed Features#

Long term#

Build a totally new Themes Playground, that is more designer and team work friendly. Maybe a "Pro" version of the Themes Playground? The current version is still after all "only" a developer's FlexColorScheme API configurator. The Playground is not really a part of the package, but more like a bonus feature. It might become its own app. You can find some more info about that here.

Out of Scope#

Serialization of FlexColorScheme#

Including built-in serialization of FlexColorScheme, and its key classes has been suggested. I consider FlexColorScheme to be functionally on a level similar to ThemeData and ColorScheme. Therefore, it should not cover serialization of itself. Serialization has to deal with a lot of potential failure points. We think it should not have to be a concern in this type of component. There is no plan to add it.

Our recommendation for saving the state of a FlexColorScheme is to include values for its settings that you use in your implementation in other models in your application, like an "AppSettings" model or similar.

You probably serialize and store such data already, perhaps with shared preferences, hive, isar, get_storage or some other solution. Include the values you need for your FlexColorScheme implementation in your stored settings and then use those values to restore your FlexColorScheme configuration and theme. This way, your implementation also remains in control of what it needs to store and restore.

From version 4.0.0, a simple approach using the architecture introduced via the Flutter "skeleton" template in Flutter version 2.5 was used together with Shared Preferences and Hive to persist and load FlexColorScheme on start. This is just one example, other implementations together with Riverpod, Provider, Flutter Bloc, GetX etc., and completely different local persistence packages work well too.