Repository navigation
Remove Deprecated API that has reached EOL after Flutter 2.10 #98537
Description
Activity
Hi, I was working on removing these deprecations. There are two more deprecations that i found in release notes of 2.0.0
- build ios-framework --universal deprecation pr
- Android v1 embedding classes deprecation pr
Hi @amanv8060! Thanks for contributing! This is meant to track the progress of removing deprecated code in the framework as defined in the deprecation policy.
I think those deprecations will be removed at a different time.
Hi @Piinks nice collection of coming removal of @deprecated APIs in post 2.10.x stable release, quite a few coming breaking changes in next stable release then. And thanks @timsneath for tweeting out a heads up notice about it too.
I collected my quick findings on the deprecated buttons topic, I mentioned on Twitter here, plus some additional findings I noticed while at keyboard and looking into it out of curiosity.
ButtonThemeData
The
ButtonThemeDataclass is marked as obsolete in the docs, but not as deprecated.In its theme
ButtonTheme:
And in its theme data
ButtonThemeData:
In addition to the buttons that will be removed, the theme and theme data is used by the buttons' parent class
MaterialButtonand theButtonBarand its themeButtonBarTheme, plus as far I could noticeDropdownButtonuses one property from it as well.Instead of having the docs above mention that it is used by buttons that will no longer exist, maybe consider updating the doc comment and instead mention the usage by
ButtonBar,DropdownButtonandMaterialButton, if it will remain. It kind of will have to, but more on that below.Perhaps for the update also consider updating the doc comment for the
buttonThemeproperty inThemeDatato better reflects its remaining usage inButtonBar,DropdownButtonandMaterialButtonMaterialButton
Next comes the question of the fate of the
MaterialButtonthe parent class for the buttons to be removed.It is also in the docs marked as obsolete but not deprecated.
Will it remain available or be removed? My conclusion is, it will stay, even if it does not correctly implement or enable users to create Material buttons, plus its children will be gone due to same reasons. Considering this, it seems a bit illogical for it to remain, but it would be difficult to remove without a number of other changes discussed further below.
My search did no reveal any other usages and mentions of
MaterialButtonthan in its child buttons that will be removed, and inButtonThemeDataitself, in a large number of odd looking getters.In
ButtonStyleButtonthere is also a doc ref toMaterialButtonthat I suspect should be toButtonStyleButtoninstead, or just as a normal text "Material button" as a reference to the Material button concept itself, rather than a doc ref to a class that has nothing to do withButtonStyleButtonwhere the reference is.The fact that
ButtonThemeData, that needs to remain forButtonBarandDropdownButton, itself depends onMaterialButton, also makes it impossible to remove the "obsolete"MaterialButtonparent of all the 3 buttons now being removed.In
Materialthere is in theMaterialTypeenum a doc comment toMaterialButtonin enum valuebutton.
So I checked for references to
MaterialType.button, other than inMaterialit is only used byRawMatererialButtonandButtonStyleButton. maybe consider updating the above doc ref to them instead ofMaterialButton.If the
MaterialButtonis considered and marked as obsolete in the docs, which imo is correct, thus maybe consider deprecating it and plan for changes need to be able to remove it.ButtonBar
Since
ButtonBaruses theButtonThemeDataand it is still a component with a "kind of" legit claim to do so, thenButtonThemeDatadoes indeed need to remain for it to work.The setup with
ButtonBarusing two different component themesButtonThemeDataandButtonBarThemeDatawith the later overriding 6 properties, if defined in "parent"ButtonThemeDataplus having 3 extra properties, and using some others from the 1st one too, "may" be a bit confusing for users trying to style it with the component themes.I used a similar approach with custom themes for custom components. It was confusing to users to have two partially overlapping themes used in similar manner for effective result. I ended up simplifying it by just using one component theme per component. In retrospect I was just being lazy and reusing props from another kind of "parent" component theme, instead of defining them separately also in the other similar component. The refactored version ended up being cleaner by keeping the theme concerns separated.
Later on, maybe consider deprecating the properties
ButtonBaruses inButtonThemeDataand provide replacements inButtonBarThemeData, it would imo be simpler and cleaner to use it then.DropdownButton
Lastly, and yes I did not see it first, you were right, the Dropdown button also uses
ButtonThemeData, but apparently only one property from it:ButtonTheme.of(context).alignedDropdown, twice, here:and here
So there is indeed that too. Maybe later consider if
DropdownButtonshould get its own component theme as well one day. It could then have some more and independent styling capabilities too.Summary
I got curious about how it all of this fits together and thought I might just as well write it down while looking into it, perhaps some of it is useful.
Mostly observations on documentation clean-up suggestions, to do after the deprecated buttons
FlatButton,RaisedButtonandOutlineButtonare removed.Plus some observations of a potential path to enable removing the
ButtonThemeDataandMaterialButtonif that is also on the clean-up agenda. Had the implementation of other features used better separation, they would now not had any references anywhere and already been removable, provided the policy would permit it of course.
OT
Now I'm going back to reading up on all the cool Material 3 changes/PRs moving forward on master. I need to see if there something more in there that I can prepare for in advance.BTW I really like the new MaterialColorUtilities, the color algos for computing M3 tonal palettes are so fab. Already using it in a WIP version in FlexColorScheme to enable using primary, secondary and tertiary key colors for scheme generation, rather than the just the single key seed color (primary) offered by
ColorScheme.fromSeed.I was a bit surprised to see MaterialColorUtilities used as a Flutter SDK pub.dev package dependency in
ColorScheme, and not having its code baked into the framework itself. That is actually quite unusual for the type of features it provides. Even a first I would say, other pubspec deps are much lower level. Typically "high" level features similar to MaterialColorUtilities are baked into the framework.Will we see more of this approach going forward? Or is this an exception or only temporary as a package import? If it is a change of style and Flutter is going to see more add-on being used in the framework as package imports, it might be of general interest to hear more about it, just a thought.
Reacted by Kate LovettReacted by Kate Lovett and Tim Sneath@rydmike thank you!! This is an amazing wrap-up. Much appreciated.
I have not been working directly on the theme overhaul (Paging @darrenaustin & @HansMuller) so I do not know the answers to all of these questions, but I think they are all very important. I am going to open an issue for each section here for discussion and review. I don't want any bit of your breakdown to go unaccounted for. :)
Couple of quick notes though for the scope of this issue's work
Instead of having the docs above mention that it is used by buttons that will no longer exist, maybe consider updating the doc comment and instead mention the usage by ButtonBar, DropdownButton and MaterialButton, if it will remain. It kind of will have to, but more on that below.
Perhaps for the update also consider updating the doc comment for the buttonTheme property in ThemeData to better reflects its remaining usage in ButtonBar, DropdownButton and MaterialButton
Certainly any and all doc references will be updated as deprecated API is removed, I've made note of these cases and will include them in my changes. Thanks very much!
I'll link back the issues that will be generated from this feedback.
Reacted by RydmikeSee associated issues above.
@rydmike I did come across these design docs, they may be of interest to youReacted by RydmikeThanks @Piinks for the design doc links. Yes I'm familiar with them, especially the theme system updates one and the issue tracking its progress #91772, I have been following its action items closely and PRs concerning it too. I might have some observations/questions on a few colors that might be missing, and if so perhaps should be added to the list. I will double check that and drop a comment in the collection issue, if that is the case.
Glad if the above review was helpful. Creating separate actionable follow-up items from it was good idea too 👍🏻
Reacted by Kate LovettThis thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.- locked as resolved and limited conversation to collaborators
on Apr 28, 2022
Internal: b/226976190
The time has come again. :)
These are the next batch of deprecations that have expired.
This one is a bit more significant than last batches, so it may take some time to get everyone migrated.
This should only be closed after the final migration guide for this batch lands in the website repo.
Notes