ThemeData config - what is it for?

[romanr]

Hi Mike!

Playground produces ThemeData config that you can copy and… where does it fit? I've spent looking through different examples and in every usage the theme code was modified.

theme: FlexThemeData.light(
  colors: const FlexSchemeColor(
    primary: Color(0xff004881),
    primaryContainer: Color(0xffd0e4ff),
____. . . 
  useMaterial3: true,
  // To use the Playground font, add GoogleFonts package and uncomment
  // fontFamily: GoogleFonts.notoSans().fontFamily,
),
darkTheme: FlexThemeData.dark(
  colors: const FlexSchemeColor(
    primary: Color(0xff9fc9ff),
____. . .
    navigationRailBackgroundSchemeColor: SchemeColor.surface,
  ),
  visualDensity: FlexColorScheme.comfortablePlatformDensity,
  useMaterial3: true,
  // To use the Playground font, add GoogleFonts package and uncomment
  // fontFamily: GoogleFonts.notoSans().fontFamily,
),
// If you do not have a themeMode switch, uncomment this line
// to let the device system mode control the theme mode:
// themeMode: ThemeMode.system,

for example to store it as a class you'll have to change:

theme: FlexThemeData.light(

to

class ThemeConfig {
  static final lightTheme = FlexThemeData.light(

and also change middle and end.

But it looks like ThemeData is formatted that way with some usage in mind. Would it fit as is or not?

I am looking if it's possible to actually paste theme into file in automated way, without rewriting methods, etc.

[rydmike]

Hi Roman,

Thanks for your question. I'm maybe not 100% sure I fully understand the question, but I will try to answer anyway, and hope that some of my explanations provide the insights you are looking for.

The FlexThemeData.light() and FlexThemeData.dark() are advanced, well at least very involved, ThemeData object factories.

What they do is based on any given config, spit out a ThemeData.raw object, which is the actual constructor of the ThemeData data class object. Their input are also put through Flutter's ThemeData() factory constructor to do so.

Flutter's ThemeData() is not a direct object constructor, it very much like FlexThemeData.light/dark() is also a factory constructor, that does a lot of massaging and compute based on the input, before it creates the ThemeData.raw object, which is the actual class constructor.

Additionally, both FlexThemeData.light() and FlexThemeData.dark() are convenience methods (made with extensions) for FlexColorScheme.light().toTheme and FlexColorScheme.dark().toTheme.

In early versions of FlexColorScheme there were only these methods to create the actual ThemeData object from a FlexColorScheme data class object.

The FlexColorScheme.light() and FlexColorScheme.dark() are factories for the raw FlexColorScheme() object constructor, that while possible there really is no major need to use directly.

In most use cases it is more convenient to just use FlexThemeData.light() and get a ThemeData object directly, as a FlexColorScheme() object has very little utility in Flutter.

However, you can use it to extract the ColorScheme it will get when it creates a ThemeData object and use that ColorScheme in customized own component theme overrides. Where you most likely want access to the same ColorScheme, that e.g. the FlexThemeData.light() created ThemeData will get.

By using FlexColorScheme.light/dark() and its toScheme method, you can get access to this ColorScheme before you have created the ThemeData object and use one step less for this type of customization. Like so:

  final FlexColorScheme flexScheme = FlexColorScheme.light(...);
  final ColorScheme colorScheme = flexScheme.toScheme;
  final themeData flexScheme.toTheme.copyWith(toggleButtonsTheme: myToggleTheme(colorScheme));

This is discussed in more detail here: https://rydmike.docs.page/flex_color_scheme_docs/api_guide#use-flexcolorscheme-or-flexthemedata

Configuring ThemeData Objects

When it comes to storing and accessing a ThemeData object made by FlexThemeData.light()/FlexThemeData.dark() or FlexColorScheme.light().toTheme/FlexColorScheme.dark().toTheme you can do that in other files, as a final global, as static finals in a class, pass in props or use controllers from whatever state management solution you like, as its input to configure it or dynamically change it based on user input. Anything Flutter and Dart can do here is fine.

The last tutorial step, example 5, which is the Themes Playground app itself, this is shown in its MaterialApp setup here:

https://rydmike.docs.page/flex_color_scheme_docs/tutorial5#materialapp-setup

In this case for state management, it uses a controller made with a Flutter ChangeNotifier and the entire MaterialApp is wrapped in a ListenableBuilder to rebuild the app's active theme whenever the user changes any of the hundreds of config props in the Themes Playground / example5 app has.

As you have seen, the Themes Playground app, not only makes a FlexColorScheme API config for the theme you configure and show it in a some sample demo apps in mock device simulators, the Playground app itself also uses, via FlexColorScheme, the theme you configure as its own active theme. It changes its own app theme interactively with every little change you make, and also updates the API code for it, as you make changes.

---

Not sure if any of this helped with your question, if not, just ask more 😄

[romanr]

Thank you.
I actually read that exact paragraph just before asked. Kind of expecting it to say that ColorScheme is just colors, and ThemeData is colors plus everything else in theme.
Maybe it's from the times at the beginning of FlexColorTheme when it was mainly about colours only. In present times, most apps can't do without ThemeData customisations. Although in some products it may be omitted, elements like corner radius, shadows, and line weights are specified in nearly every modern design system.

---

To my question about generated code, main.dart should be small and modular, not having the whole ThemeData pasted in it. With preset themes, it's easy by assigning ThemeData like const FlexScheme usedScheme = FlexScheme.mandyRed; For custom themes, there's example 2 in which the theme is simply pasted into main.dart.

In example 5 looks like the theme is split into 4 files: flex_theme_dark, _light, theme_data_light, _dark.
If we want to provide the end-user with a choice of themes within the app, we would export ThemeData from Playground, and then we would have to create a class that consumes ThemeData.

Would it make sense for FlexTheme to generate the whole class in the first place?
Or even better, as a more future-proof approach, Playground could generate a Theme in JSON (compatible with Material Theme Builder), and we could have a FlexTheme JSON consumer that takes the theme JSON and creates a runtime theme instance. No coding or pasting of theme code would be required.

Right now, everything has to be done manually, which is especially complex if you want to offer multiple themes for the user to choose from.

FlexTheme could be something like a code generator in the overall process; during the build, along with localization, it could generate color themes stored in /assets as JSON.

With the example of the Flutter 3.22 calamity with M3 theming API changes, such a workflow would automatically update the project with the updated definitions of themes as necessary.
👨‍🎨

[rydmike]

Yes devs are welcome to and typically do put the generated FCS API code somewhere else than in the MaterialApp, just like you do with vanilla ThemeData too.

For hoking it up to own const tokens values or dynamic user inputs (I do both too), I typically when I want to add something a previously made config, just toggle the config in the Playground back and forth, to see what prop it was again, and then copy/paste just that row to wherever I have my FCS theme config.

Optionally, I override FCS value with a token from Figma, other tool, mostly they in a const token Dart file OR if it is a dynamic user config prop, then I tie it to the controller property, like example 5 does. It could be Riverpod providers or Signals, I've certainly done that too.

Yes, the examnple 5 (Playground) has 4 themes, because it provides separate light/dark themes for when user of the Playground app turns OFF using FlexeColorScheme, it then uses vanilla ThemeData with same ColorScheme and visual density and font as otherwise active in the Playground when the when FlexColorScheme is being used.

I use the OFF mode in the Playground, to see and compare what vanilla ThemeData does in M2 and M3 mode, using the same ColorScheme.

Thanks for the input on the other topics, concerning future versions 💙

[rydmike]

By the way and for info FCS 8.0.0 is out as early access as 8.0.0-dev.1

With it, as an option, you can copy/paste the theme config pre-made for use in its own file.

FlexColorScheme package dev release 8.0.0-dev.1 has been published. This is a BIG update with breaking changes and many new features. It has its own dev pre-release of the Themes Playground as well, feel free to take a look. No new API changes are planned for the stable 8.0.0 release from this dev.1 release.

We would appreciate any feedback about found issues from early adopters.

• Doc site has some pre-info
• Dev release of PKG here
• The PKG changelog has the most detailed info

FOR INFO there will be no new features or changes in it compared to this one. Only any issues found from the quality assurance will be addressed. The stable release will also include many doc updates, but docs site will continue to be edited and revised AFTER the 8.0.0 stable release.

[rydmike]

And now it is released as 8.0.0 stable

• https://github.com/rydmike/flex_color_scheme
• https://rydmike.com/flexcolorscheme/themesplayground-latest/
• https://docs.flexcolorscheme.com/whats_new