Normalize input decoration theme #168981

bleroux · 2025-05-16T15:14:32Z

This PR is to make InputDecorationTheme conform to Flutter Material's conventions for component themes:

Added a InputDecorationThemeData class which defines overrides for the defaults for InputDecorator properties.
Added InputDecorationTheme constructor parameters: InputDecorationThemeData? data and Widget? child. This is now the preferred way to configure a InputDecorationTheme:

InputDecorationTheme(
	data: InputDecorationThemeData(
	    filled: true,
	    fillColor: Colors.amber,
	    ...
	  ),
  	child: const TextField()
)

These two properties are made nullable to not break existing apps which has customized ThemeData.inputDecorationTheme.

Update InputDecorationTheme to be an InheritedTheme subclass.
Changed the type of component theme defaults from InputDecorationTheme to InputDecorationThemeData.
Changed the InputDecorationTheme bottomAppBarTheme property to Object? bottomAppBarTheme in ThemeData and ThemeData.copyWith() (Object? is used for the moment to minimize Google tests failure. A follow-up PR will replace Object? with InputDecorationThemeData.
Addresses the "theme normalization" sub-project within ☂️ Material Theme System Updates #91772.

A migration guide will be created on website repo.

bleroux · 2025-05-16T15:17:51Z

@QuncCccccc This PR sets ThemeData.InputDecorationTheme type to Object? to simplify the migration.

Because, InputDecorationTheme is used by several widgets as a property, for instance DropdownMenu.inputDecorationTheme, let me know if Object? should also be use for these properties?

QuncCccccc · 2025-05-16T17:27:51Z

I think we can leave it for now until we decided to clean up the properties in InputDecorationTheme. The reason why we change the type of ThemeData.xxxTheme to Object? is we want merging this PR and the g3 fixing to be two independent steps. If we change the type to xxxThemeData directly, the PR will be blocked until we provide a g3fix and make them roll in together. So this middle step is just to provide a soft land for the whole process, so I think we don't need to change other usage of InputDecorationTheme because seems they won't cause the breakages:) Please let me know if anything don't make sense 😊!

QuncCccccc

Overall looks good to me! Thanks so much for working on this big theme! Just left some comments, please let me know if you have any thoughts on them:)

QuncCccccc · 2025-05-20T23:13:33Z

examples/api/lib/material/dropdown_menu/dropdown_menu.0.dart

@@ -9,7 +9,7 @@ import 'package:flutter/material.dart';
 // has the default outlined border and demos using the
 // [DropdownMenuEntry] style parameter to customize its appearance.
 // The second dropdown menu customizes the appearance of the dropdown
-// menu's text field with its [InputDecorationTheme] parameter.
+// menu's text field with its [inputDecorationTheme] parameter.


I think the brackets are used to show the API link, so not sure whether changing it here will break the link. Maybe use ``?

Good catch! In that particular case it should be [DropdownMenu.inputDecorationTheme]. My goal was to point to the parameter documentation not the type documentation.

QuncCccccc · 2025-05-20T23:24:39Z

packages/flutter/lib/src/material/date_picker_theme.dart

@@ -413,7 +413,7 @@ class DatePickerThemeData with Diagnosticable {

  /// Overrides the [InputDatePickerFormField]'s input decoration theme.
  /// If this is null, [ThemeData.inputDecorationTheme] is used instead.
-  final InputDecorationTheme? inputDecorationTheme;
+  final InputDecorationThemeData? inputDecorationTheme;


I'm actually not sure if we should change the parameter type here because it may introduce more breaking changes. Do you think if it would be better to change the type when we are really removing the properties in InputDecorationTheme?

Similar for other widgets, just feel these public apis may cause too many breaking changes.

Makes sense. I reverted this changes and just kept the ThemeData.inputDecorationTheme change.

QuncCccccc · 2025-05-21T16:51:56Z

packages/flutter/lib/src/material/dropdown_menu.dart

@@ -158,7 +158,7 @@ class DropdownMenu<T> extends StatefulWidget {
  /// in the [InputDecoration.prefixIcon] and [InputDecoration.suffixIcon].
  ///
  /// Except leading and trailing icons, the text field can be configured by the
-  /// [InputDecorationTheme] property. The menu can be configured by the [menuStyle].
+  /// [inputDecorationTheme] property. The menu can be configured by the [menuStyle].


Same here:)

Here it will be ok, as the link will point to the inputDecorationTheme parameter documentation.

QuncCccccc · 2025-05-21T17:12:14Z

packages/flutter/lib/src/material/input_decorator.dart

@@ -3994,7 +3995,7 @@ class InputDecoration {
  ///
  /// Only null valued properties from this [InputDecoration] are replaced
  /// by the corresponding values from [theme].
-  InputDecoration applyDefaults(InputDecorationTheme theme) {
+  InputDecoration applyDefaults(InputDecorationThemeData theme) {


Also for the type of the parameter, I'm a little hesitant to change it as well. I feel it would be better if we can just keep minimum breaking changes in ThemeData

The problem here is that most of the applyDefaults usages on the framework code call it in the following way:

applyDefaults(Theme.of(context).inputDecorationTheme)

And because of this PR, Theme.of(context).inputDecorationTheme returns a InputDecorationThemeData.
So if we change the applyDefaults parameter type to InputDecorationTheme, we would need to update all existing calls to wrap the result of Theme.of(context).inputDecorationTheme in a InputDecorationTheme.

I'm not sure which solution is less breaking and for the moment, I don't see a solution to make this non breaking.

Yeah... it makes sense. Thanks for your explanation. Theme.of().xxxTheme is definitely a breaking change but I'm not sure if we have any ways to avoid it.

For applyDefaults(), I noticed there are several usages in g3, some use cases get the theme from Theme.of().inputDecorationTheme and some use cases get the theme from other component theme parameter such as timePickerTheme.inputDecorationTheme. Since we don't want to change the parameter type in other component theme, now I would lean more towards changing the parameter type in applyDefaults() to Object until I fix the g3 use cases, or just leave it as Object to accept both until we are really removing properties in InputDecorationTheme. Do you think if it makes sense? Please let me know if there's any concerns.

Yes, it makes perfectly sense 🙏
I updated the PR to change the applyDefaults() parameter type to Object.

Seems the parameter type is still InputDecorationThemeData:) Maybe forget to push the code change?

Maybe forget to push the code change?

Exactly! Sorry for this, it should be better now 😅

guidezpl mentioned this pull request May 16, 2025

☂️ Material Theme System Updates #91772

Open

42 tasks

bleroux force-pushed the input_decoration_theme_normalization branch from 7e4398b to 520a3d9 Compare May 16, 2025 16:51

bleroux force-pushed the input_decoration_theme_normalization branch 2 times, most recently from e87d275 to 02b9d21 Compare May 16, 2025 20:55

bleroux requested a review from QuncCccccc May 20, 2025 15:24

QuncCccccc reviewed May 21, 2025

View reviewed changes

bleroux force-pushed the input_decoration_theme_normalization branch 7 times, most recently from 673b58e to 06d1336 Compare May 23, 2025 15:13

huycozy mentioned this pull request May 26, 2025

Normalize BottomAppBarTheme #168586

Merged

9 tasks

bleroux force-pushed the input_decoration_theme_normalization branch 4 times, most recently from a08dca9 to 6d5b2f4 Compare May 27, 2025 07:28

bleroux requested a review from QuncCccccc May 27, 2025 08:30

bleroux added 2 commits June 3, 2025 09:01

Normalize input decoration theme

2fbdacc

Normalize only ThemeData.inputDecorationTheme

eec1eb6

bleroux force-pushed the input_decoration_theme_normalization branch from 6d5b2f4 to 80609ec Compare June 3, 2025 07:01

InputDecoration.applyDefaults accepts Object

32f1bd0

bleroux force-pushed the input_decoration_theme_normalization branch from 80609ec to 32f1bd0 Compare June 3, 2025 08:40

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Normalize input decoration theme #168981

Normalize input decoration theme #168981

Uh oh!

bleroux commented May 16, 2025

Uh oh!

bleroux commented May 16, 2025

Uh oh!

QuncCccccc commented May 16, 2025

Uh oh!

QuncCccccc left a comment

Uh oh!

QuncCccccc May 20, 2025

Uh oh!

bleroux May 27, 2025

Uh oh!

QuncCccccc May 20, 2025

Uh oh!

bleroux May 27, 2025

Uh oh!

QuncCccccc May 21, 2025

Uh oh!

bleroux May 27, 2025

Uh oh!

QuncCccccc May 21, 2025

Uh oh!

bleroux May 27, 2025

Uh oh!

QuncCccccc May 31, 2025 •

edited

Loading

Uh oh!

bleroux Jun 2, 2025

Uh oh!

QuncCccccc Jun 3, 2025

Uh oh!

bleroux Jun 3, 2025

Uh oh!

Uh oh!

Normalize input decoration theme #168981

Are you sure you want to change the base?

Normalize input decoration theme #168981

Uh oh!

Conversation

bleroux commented May 16, 2025

Uh oh!

bleroux commented May 16, 2025

Uh oh!

QuncCccccc commented May 16, 2025

Uh oh!

QuncCccccc left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

QuncCccccc May 31, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

QuncCccccc May 31, 2025 •

edited

Loading