Proposal: Add `themeBuilder` to MaterialApp to eliminate theme duplication

[chika3742]

Use case

Flutter recommends using ThemeData.from(colorScheme: ...) together with ColorScheme.fromSeed(..., brightness: brightness). With this pattern, the only thing that differs between light and dark themes is Brightness — almost of settings not related to color (typography, shape, component themes, some of ThemeExtensions, etc.) are identical.

However, MaterialApp only accepts fully-specified ThemeData objects for each of theme, darkTheme, highContrastTheme, and highContrastDarkTheme. The only way to avoid duplication is to define a helper function on the user side:

MaterialApp(
  theme:              _buildTheme(Brightness.light, false),
  darkTheme:          _buildTheme(Brightness.dark,  false),
  highContrastTheme:  _buildTheme(Brightness.light, true),
  highContrastDarkTheme: _buildTheme(Brightness.dark, true),
)

ThemeData _buildTheme(Brightness brightness, bool highContrast) =>
    ThemeData.from(
      colorScheme: ColorScheme.fromSeed(
        seedColor: kSeedColor,
        brightness: brightness,
      ),
    ).copyWith(
      cardTheme: ...,
      inputDecorationTheme: ...,
      extensions: [AppColors.fromBrightness(brightness, highContrast)],
    );

The framework offers no first-class support for this pattern, so developers unfamiliar with it naturally write separate ThemeData objects for each property, leading to drift over time.

Proposal

Add a themeBuilder property to MaterialApp with the following signature:

themeBuilder: (Brightness brightness, bool highContrast) => ThemeData

Example usage:

MaterialApp(
  themeBuilder: (brightness, highContrast) => ThemeData.from(
    colorScheme: ColorScheme.fromSeed(
      seedColor: Colors.blue,
      brightness: brightness,
    ),
  ).copyWith(
    cardTheme: const CardThemeData(elevation: 2),
    inputDecorationTheme: const InputDecorationTheme(
      border: OutlineInputBorder(),
    ),
    extensions: [
      AppColors.fromBrightness(
        brightness,
        highContrast,
      ),
    ],
  ),
  themeMode: ThemeMode.system,
)

When themeBuilder is provided, MaterialApp calls it internally with the resolved Brightness and highContrast, replacing the need for theme, darkTheme, highContrastTheme, and highContrastDarkTheme. If dark theme is not needed, the brightness argument can simply be ignored.themeBuilder and those four properties would be mutually exclusive (assertion error if both are set). themeMode continues to work as-is.

Additionally, since there is no need to instantiate a separate ThemeData for each theme variant upfront, there may be a marginal performance improvement.

[QuncCccccc]

Thanks for the proposal! While this approach is an elegant way to handle standard system-driven theme switching, it introduces a design challenge regarding the builder's signature. We would need to be careful about which parameters are included. Like, would (Brightness brightness, bool highContrast) be enough? If the framework needs to support additional inputs later (e.g., dynamic color seeds from Android, platform targets), changing the builder signature would easily become a breaking change.

Because of this signature complexity and the risk of breaking changes, I think the helper function on the user side you mentioned might actually be the better, more flexible solution for most apps. It gives developers complete control to pass any parameters they need without requiring the framework to predict all future theming inputs, and it avoids further expanding the already large MaterialApp API surface. Please let me know your thoughts!

[chika3742]

@QuncCccccc Thank you for your reply!

If these inputs are to be increased, the number of MaterialApp's theme-related parameters will also increase exponentially, so I believe that migrating to a function format will be necessary sooner or later. I made this signature explicit to clearly indicate that the theme will be rebuilt (without rebuilding the parent of MaterialApp) when these values are changed.

A possible solution is to create a new class such as ThemeBuilderParams, store information like brightness in it, and pass it as an argument. This allows for adding values safely.