This is tricky. ThemeData.inputDecorationTheme contains overrides for the defaults computed by components like DatePicker. If the developer specifies DatePickerTheme.inputDecorationTheme, they're eliminating the ThemeData overrides. From a build method they could merge their overrides like this:

Theme.of(context).inputDecorationTheme.copyWith(
  backgroundColor: Colors.green,
)

But that's not practical if the InputDecorationTheme is created outside of a build method (because BuildContext). It might be useful to add an InputDecorationTheme.merge method like ButtonStyle.merge and use it in the DatePicker implementation.

It might make sense to do that for DropdownMenu as well.
CC @QuncCccccc

But that's not practical if the InputDecorationTheme is created outside of a build method (because BuildContext). It might be useful to add an InputDecorationTheme.merge method like ButtonStyle.merge and use it in the DatePicker implementation.

Thansk for the review! Sure I can do that

This is tricky. ThemeData.inputDecorationTheme contains overrides for the defaults computed by components like DatePicker. If the developer specifies DatePickerTheme.inputDecorationTheme, they're eliminating the ThemeData overrides. From a build method they could merge their overrides like this:

So the expected behavior:

• Use DatePickerTheme.inputDecorationTheme if provided.

• If both DatePickerTheme.inputDecorationTheme and ThemeData.inputDecorationTheme is provided, it default to the theme data input decoration theme.

is that right?

What I was suggesting: if DatePicker.inputDecorationTheme is provided then merge it with ThemeData.inputDecorationTheme. That way ThemeData.inputDecorationTheme properties that are null in DatePicker.inputDecorationTheme will still be used.

@HansMuller and @TahaTesser, the used .merge may also reduce the usability (oops read the edit, it is very bad) and make it confusing to use the inputDecoratorTheme.

Also the behavior is now different from how same inputDecoratorTheme behaves and has always behaved in the TimePickerDialog where the provided inputDecoratorTheme just replaces the entire default one, and does not merge it. If props are null in it, you just get default from default decorator behavior (mostly anyway, it does some hidden "magic" with a few props).

Why do I call it less usable and confusing?

If I create a custom InputDecorator style for the TimePickerDialog and DatePickerDialog. Then for the TimePickerDialog I can just provide one that is straight up using desired deign, but for the DatePickerDialog I also have to provide values for properties that might be null in my custom one, and I expect it fall back to default input decorator behavior, but I must now know to provide overrides to some values I did not have to override for TimePickerDialog.inputDecorationTheme.

One might e.g. have a highly customized ThemeData.inputDecorationTheme, but say we only want to use that for TextFields in the app, but want to have the M3 default style in the TimePickerDialog and DatePickerDialog for their input fields.

Getting such a result is both very tricky and confusing. In neither case can I provide null or just an InputDecorationTheme() the inputDecoratorTheme to get that result, and what I have to do, actually varies between TimePickerDialog and DatePickerDialog. For TimePickerDialog it is doable to get back to defaults, even if that also requires a very elaborate theme inputDecoratorTheme using default from the private default class, for DatePickerDialog it becomes pretty hopeless... still trying to do so.

Imo it is clearest the way the DropdownMenu does it. It uses its own default style, does not inherit from ThemeData.inputDecorationTheme, if you want something else, you give it, its own inputDecorationTheme, but then you are on your own with how it fits.

If you want the global style you made for ThemeData.inputDecorationTheme you have to pass the same defs to its DropdownMenuThemeData.inputDecorationTheme. Simple and understandable imo.

Of course it does take away from at least a vague comment statement that ThemeData.inputDecorationTheme is supposed to be general configuration of the InputDecorator in an app. However, it already is not, both TimePickerDialog and DatePickerDialog do their own little tweaks to it anyway, but also inherits chunks from it.

Different behavior

All in all we now have as far as I know, four different styles for how inputDecoratorTheme behaves in components.

• DatePickerDialog : merge, must provide none nulls to get back to widget defaults.

• TimePickerDialog : ?? fall through, but must provide some internal fixes (errorStyle), values for things that come from global input decorator (like hover color)

• DropdownMenu : Does not use global default, pass it what you want or else it uses own default.

• SearchBar : Removes all input decorator themes and always does its own style. It did not uses to do that, it had to be fixed to so, since some props from ThemeData.inputDecorationTheme leaked through when you customized it and and destroyed the intended design of SearchBar

Somehow it feels like DropdownMenu approach is the simplest one, and its behavior could be extended to SearchBar by giving it a inputDecorationTheme as well, if someone wants to style it a bit, which cannot even be done now.

The DatePickerDialog and TimePickerDialog approaches are messy. They have very elaborate custom input decorations as default (Like SearchBar does too), and go out of their ways to retain some of when you provide a custom style, if you did not specify that prop, instead of sticking to ONLY using internal style if you did not give it anything and then using purely whatever custom style you gave it, if you give one.

I think these kind of differences may further contribute to why some devs find theming in Flutter difficult and confusing. Still, much better than no config option at all 😄 👍🏻

EDIT

The merge in the InputDatePickerFormField is VERY problematic, it only merges the style if I have not defined a style in theme.inputDecorationTheme, if it is null, so we do NOT get the style defined in datePickerTheme.inputDecorationTheme if one is already defined in theme.inputDecorationTheme. Thus with a very elaborate theme.inputDecorationTheme, that defines pretty much all properties it has, that is still the only style we can get, despite the addition of the datePickerTheme.inputDecorationTheme. This is of course because of how merge works, where it only fills in none null fields in inputTheme below, and if all the fields in inputTheme are none null, the merged datePickerTheme.inputDecorationTheme has no impact whatsoever.

  @override
  Widget build(BuildContext context) {
    final ThemeData theme = Theme.of(context);
    final bool useMaterial3 = theme.useMaterial3;
    final MaterialLocalizations localizations = MaterialLocalizations.of(context);
    final DatePickerThemeData datePickerTheme = theme.datePickerTheme;
    final InputDecorationTheme inputTheme = theme.inputDecorationTheme;
    final InputBorder effectiveInputBorder =  datePickerTheme.inputDecorationTheme?.border
      ?? theme.inputDecorationTheme.border
      ?? (useMaterial3 ? const OutlineInputBorder() : const UnderlineInputBorder());

    return TextFormField(
      decoration: InputDecoration(
        hintText: widget.fieldHintText ?? localizations.dateHelpText,
        labelText: widget.fieldLabelText ?? localizations.dateInputLabel,
      ).applyDefaults(inputTheme
        .merge(datePickerTheme.inputDecorationTheme)
        .copyWith(border: effectiveInputBorder),
      ),
      validator: _validateDate,
      keyboardType: widget.keyboardType ?? TextInputType.datetime,
      onSaved: _handleSaved,
      onFieldSubmitted: _handleSubmitted,
      autofocus: widget.autofocus,
      controller: _controller,
    );
  }
}

Maybe if merge is to be used, instead consider:

      ).applyDefaults((datePickerTheme.inputDecorationTheme ?? InputDecorationTheme())
        .merge(inputTheme)
        .copyWith(border: effectiveInputBorder),
      ),

At least then we get datePickerTheme.inputDecorationTheme props where given and back filled with the inputTheme = theme.inputDecorationTheme.

@rydmike
Thanks for raising this. Can you please file a separate issue with the details?

@TahaTesser, sure, later (maybe in month or so when I have the energy and time, a bit beat at the moment).

This should perhaps not have been merged like this, it does not work at all if you have a theme.inputDecorationTheme defining all the props already.

However, by switching what is merged into what, as shown in the edit above, it at least can do what I suspect it was supposed to do for DatePickerDialog. Even with that, getting back to defaults is still very difficult for both DatePickerDialog and TimePickerDialog, if you have a very custom theme.inputDecorationTheme, but at least it is doable then.

The DropdownMenu setup is just the simplest one to use. Don't change it (#131213), these two other approaches are messy to use. Or at the very least, if it is inherited then providing an inputDecorationTheme should just completely replace the inherited one, and default is just fallback, much clearer and simpler to use.

@TahaTesser, I tried the setup by using the above proposed order instead:

      ).applyDefaults((datePickerTheme.inputDecorationTheme ?? InputDecorationTheme())
        .merge(inputTheme)
        .copyWith(border: effectiveInputBorder),
      ),

At least then I can style datePicker with its own inputDecorator using datePickerTheme.inputDecorationTheme, as long as I explicitly override everything that is not null in theme.inputDecorationTheme. So in a way that works a bit as a ?? fallback, but on field level in the InputDecoratorTheme. A bit tedious to get desired effect, e.g. going back to default style is verbose, but yeah sure doable.

However, with the current implementation, I cannot get any impact at all from datePickerTheme.inputDecorationTheme whenever theme.inputDecorationTheme has something defined, so that must be wrong order as datePickerTheme.inputDecorationTheme does not override anything.

@rydmike
I will look into the issues described and reproduce and investigate them on Monday.

@rydmike
From what I can gather from the feedback, you expect DatePickerTheme.inputDecorationTheme to override ThemeData.inputDecorationTheme.

One thing to remember is that .merge doesn't override every property of ThemeData.inputDecorationTheme
This is documented https://master-api.flutter.dev/flutter/material/InputDecorationTheme/merge.html so the ThemeData.inputDecorationTheme has to be implemented. Only non-null properties will be merged.

The merge in the InputDatePickerFormField is VERY problematic, it only merges the style if I have not defined a style in theme.inputDecorationTheme, if it is null, so we do NOT get the style defined in datePickerTheme.inputDecorationTheme if one is already defined in theme.inputDecorationTheme.

AFAIK this was intended, for instance, fillColor from datePickerTheme.inputDecorationTheme will not be used if there is one already in ThemeData.inputDecorationTheme.

What I was suggesting: if DatePicker.inputDecorationTheme is provided then merge it with ThemeData.inputDecorationTheme. That way ThemeData.inputDecorationTheme properties that are null in DatePicker.inputDecorationTheme will still be used.

ThemeData.inputDecorationTheme takes precedence mainly because its properties filled and isCollapsed are not overridden in the .merge since they're not nullable and these properties control other properties such asfillColor

That being said and if it doesn't improve this behavior we can revert this.

This should perhaps not have been merged like this, it does not work at all if you have a theme.inputDecorationTheme defining all the props already.

This was intended AFAIK, theme.inputDecorationTheme will take precedence. Perhaps I'm mistaken? DatePickerTheme.inputDecorationTheme isn't supposed to override the theme.inputDecorationTheme. As mentioned some key properties filled are not overridden by .merge. DatePickerTheme.inputDecorationTheme should be together with theme.inputDecorationTheme with ts non-nullable properties.

That way ThemeData.inputDecorationTheme properties that are null in DatePicker.inputDecorationTheme will still be used.

Only properties that are null in ThemeData.inputDecorationTheme but not in DatePicker.inputDecorationTheme will be used.

cc: @HansMuller we can revert this if this isn't the intended behavior?

@TahaTesser and @HansMuller, if the DatePickerTheme.inputDecorationTheme is not supposed to override the theme.inputDecorationTheme, what is the point with it? As soon as you have defined any property to be none null in your theme.inputDecorationTheme, which you will have and have to do to style your global TextField theme style. Then when you do that, you can no longer revert or have another style in the DatePickerDialog via DatePickerTheme.inputDecorationTheme, so what is the point with the inputDecorationTheme in it then?

At least with how TimePickerTheme.inputDecorationTheme behaves, you can do that, which is desirable, even if it is messy too, since it overrides some props in it.

I still maintain that the current DropdownMenuTheme.inputDecoratorTheme is the cleanest approach. It just uses its own default style, does not use the theme.inputDecorationTheme at all, but you can give it the same style by assigning the same inputDecorationTheme to DropdownMenuTheme.inputDecoratorTheme if you want that, or any other style. Clean and simple. No merging, no random props it overrides.

As mentioned already above, the current setup with 4 different behavior concerning inputDecoration in 4 different widgets is very confusing and messy. Maybe consider a shared strategy that also works well for custom styling.

EDIT:

When you have already made a VERY custom theme.inputDecorationTheme pretty much every property in it is no longer null, so you cannot provide other values via DatePickerTheme.inputDecorationTheme the way it is now. That is why I called it pointless.

I still maintain that the current DropdownMenuTheme.inputDecoratorTheme is the cleanest approach. It just uses its own default style, does not use the theme.inputDecorationTheme at all, but you can give it the same style by assigning the same inputDecorationTheme to DropdownMenuTheme.inputDecoratorTheme if you want that, or any other style. Clean and simple. No merging, no random props it overrides.

I'm totally open to this. I think clean and no merge approach will be great.

cc: @HansMuller WDYT

Sure if a widget already depends on the inherited InputDecoratorTheme from ThemeData, to some degree, it can of course still do so, but it imo it is cleaner if that is then just completely ignored if you give it an own InputDecoratorTheme as a part of its component theme or widget prop.

It also fits well with how props work generally in component themes.

@TahaTesser and @HansMuller I opened this to capture the topics above #131666

@HansMuller it remains my firm opinion that fix is not really a fix, it is sadly not in-line with any previous similar behavior, nor does the implementation actually solve the reported issue. This is described in more detail in #131666.

I think this fix needs a new fix or it should be reverted. It just increases behavior differences and does not even allow you override the theme.inputDecorationTheme decorator for any property that is not null in it.