ChangeNotifierProvider vs Provider lint?

[filiph]

Someone just showed me provider code that didn't work for them — things were getting updated internally, the ChangeNotifier was calling notifyListeners, the widget was correctly wrapped in a relevant Consumer, there were no static or dynamic errors, but nothing changed in the UI.

The culprit, which took me several minutes to realize, was using Provider instead of ChangeNotifierProvider.

I don't think there is an easy solution for this, but I thought maybe others would have ideas.

[filiph]

One idea is to have a linter hint which would fire when you have an instance of ChangeNotifier as the value provided by the vanilla Provider.

[rrousselGit]

I'm mixed about the linter. It is a good idea but may not be used.

The main issue with custom analyzer plug-ins is that they require a separate installation step beside the pubspec dependency.

From my experience, most people don't know/have an analysis_options.yaml, and hardly any existing package offers an analyzer plug-in.
So, while possible, I doubt if its effectiveness.

[rrousselGit]

One alternative is to add an assert on Provider similar to assert(value is! Listenable && value is! Stream && value is! StreamController).

There's technically a use-case for it as we're speaking, but:

• it could be made optional. The assert check could be made from a static public closure, such that users can disable/customize it if needed
• if Expose InheritedWidget subscription cancelation flutter/flutter#33213 is merged, then that use-case is replaced entirely with something better.

[listepo]

I think linter is a good idea

[znjameswu]

I think linter is a better idea. I always use Provider to perform all kinds of dependency injection, including injecting AnimationController and various other stuff that may implement Listenable. To avoid an error, I have to always create a wrapper object.

Setting a global Provider.debugCheckInvalidValueType is just unacceptable for any library code. I think there needs to be a library-friendly solution. Adding an optional parameter in Provider constructor to explicitly allow Listenable seems to be a choice as well.

[rrousselGit]

A linter is very time-consuming to implement and the custom lint API makes it that most users would not install the linter, rendering it not very useful.

[listepo]

I think a linter plugin(like Working with Plugins) would be the best option, but I'm not sure there is such a possibility now

[rrousselGit]

There's nothing close to true plug-ins in dart.

There's something WIP, but that consumes a lot of resources (plug-ins have to re-analyze the project). They don't work with "dart analyze" or // ignore. And they need to be installed separately

[listepo]

I understand you, I am now thinking about implementation using code generation, but I agree that there are many problems

[znjameswu]

What about an optional parameter inside the Provider constructor, say bool disableInvalidValueTypeCheck = false?