Adds check for either WidgetStates or MaterialStates in useMaterialStatesController debug test

[MitchellGoodwin]

Flutter is moving MaterialState, and it's related functions outside of the Material library and changing it's name to WidgetState. MaterialState will still be available as is, just marked deprecated, and made a typedef of WidgetState. However this causes MaterialState debug functions to return with strings mentioning "WidgetState", and is a breaking change for packages using those functions. The PR that will add that change to Flutter is here, and the original issue is here.

Internal testing found this caused a breakage in this package, so this PR updates the test for useMaterialStatesController to pass both before and after that change is landed.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 0c19ea2

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[rrousselGit]

This feels a bit weird to me. useMaterialStatesController is explicitly instantiating MaterialStatesController

How did we end-up with a WidgetStatesController? Wouldn't we get a type error?

[rrousselGit]

Oh MaterialStatesController is deprecated and it's a typedef

[MitchellGoodwin]

It is weird. MaterialStatesController is being moved down to the widgets layer and renamed to WidgetStatesController. For migration purposes, there is still a MaterialStatesController, but it is just a typedef of WidgetStatesController, so it acts the same as how it did before. Except for the debug functions, which return strings mentioning WidgetState.

[rrousselGit]

Considering MaterialStatesController is deprecated, the failing "hook" should be deprecated too.

Does this PR have to land before #421?

I'd rather:

• wait for Adds check for either WidgetStates or MaterialStates in useMaterialStatesController debug test #421
• deprecate useMaterialStatesController
• add a useWidgetStatesController using non-deprecated API
• only use WidgetStatesController in the test (rather than have the test depend on deprecated API)

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.36%. Comparing base (15fdb4f) to head (0c19ea2).

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #421   +/-   ##
=======================================
  Coverage   98.36%   98.36%           
=======================================
  Files          21       21           
  Lines         858      858           
=======================================
  Hits          844      844           
  Misses         14       14           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[MitchellGoodwin]

Does this PR have to land before #421?

I saw that the Flutter PR broke the test in this package, so I wanted to add a fix for the test that would pass both before and after the change in Flutter. Theoretically #421 can land before flutter/142151, then a useWidgetStatesController could be added anytime before MaterialStatesController is removed after being marked deprecated.

But if you'd rather not adjust the upcoming broken test and add a useWidgetStatesController right away, then that's fine too.

[rrousselGit]

Awesome. I'd rather keep things are they are right now then.
The failing test will serve as a reminder to switch to the new API once the CI fails :)

Thanks a lot for the heads up though!

[MitchellGoodwin]

No problem. I'll close the PR 👍