Allow to inject multiple PropertyChangeProvider at the root of app

[trietbui85]

I see in provider package, they allow us to inject multiple Provider at the root of app by using MultiProvider to avoid nested Provider, like this:

@override
Widget build(BuildContext context) {
  return MultiProvider(
	providers: [
	  ChangeNotifierProvider(builder: () => homeBloc),
	  ChangeNotifierProvider(builder: () => maintainBloc),
	],
	child: MaterialApp(
	  title: 'Flutter Demo',
	  home: LandingPage()
	),
  );
}

So, could you also add an equivalent MultiPropertyChangeProvider too?

[martinrybak]

Nice! It shouldn't be too hard. To use PropertyChangeProvider with MultiProvider, all you have to do is make it implement SingleChildCloneableWidget. However that would put a dependency from this library on the Provider package. Not sure if that's a good idea.

[martinrybak]

See the multiprovider branch for a working example.

[trietbui85]

Hi @martinrybak . Thanks for that working sample. It seems not so hard to implement PropertyChangeProvider with MultiProvider. But as you said, not sure it's a good idea to include provider dependency.
Thus, I think about another approach: implement your own MultiPropertyChangeProvider instead. Is it difficult to implement that?

[martinrybak]

Probably not, but I also don't want to go down the slippery slope of duplicating other Provider package features...

[trietbui85]

Ok, I understand. So now, it's up to you to release new version of PropertyChangeProvider with provider dependency.

[martinrybak]

Do you think it's a good idea to depend on Provider? I was struggling with that question as I made this library.

[anlam87]

Hi @martinrybak , I'm using Provider + ChangeNotifier + StreamBuilder for my app. But since having your package, I'm considering to change to your lib because it solves some problems as you mentioned. However, from my real projects, MultiProvider is really necessary. It's better if the lib supports MultiProvider.
Depending on the Provider is not a bad idea because of the popular Provider. The Provider is recommended by the Google Flutter team, so the community will trust your lib if it bases on Provider.
However, you only need to use a very small part on Provider (by implementing SingleChildCloneableWidget). In my opinion, you should implement yourself. Duplicating is not important, as long as you can make a good library for yourself and for the community

[trietbui85]

IMHO, your property_change_notifier looks promising. And if I decide to use it, it would replace provider. Thus, in my (happy case), I won't have to include both property_change_notifier and provider dependencies in project.

[chimon2000]

I don't see an issue with depending on Provider if there is some functionality that provides value or reduces duplication, such as multi-provider. But if that is a major concern why not have a separate package for that?

[rrousselGit]

What about having provider use InheritedModel?

provider won't make a PropertyChangeNotifier, but it could support "aspects", which would allow a package like this one to have better integration.

What do you think?

[trietbui85]

Here is my workaround to make code shorter when using multiple PropertyChangeProvider

Widget tree = MaterialApp(
      title: 'Flutter Demo',
      theme: ThemeData(
        primarySwatch: Colors.blue,
      ),
      home: MyHomePage(),
 );
tree = PropertyChangeProvider(value: MyModel1(), child: tree);
tree = PropertyChangeProvider(value: MyModel2(), child: tree);
... 
return tree;

[martinrybak]

@rrousselGit Thanks for weighing in! Supporting aspects in Provider definitely opens the door to using it with PropertyChangeNotifer models. The tricky detail is that PropertyChangeProvider doesn't return the model directly from its of method. It returns a type that contains both the model and the changed property (aspect). That is different than the way Provider works now.

[rrousselGit]

It's technically feasible to expose the latest aspects changed. But before that, what's the use-case?

[martinrybak]

One of the features of PropertyChangeNotifier is that you can observe multiple properties with the same listener and it will tell you which one changed. However I think this effect can be achieved by simply using multiple Consumer widgets. Does anybody on this thread have a use case that could not be solved in this manner?

[KevinRohn]

Is there any update on this to use the PropertyChangeProvider with MultiProvider?

[worawutt]

See the multiprovider branch for a working example.

Note @martinrybak provider v4.0.0
The SingleChildCloneableWidget interface is removed and replaced by a new kind of widget SingleChildWidget.

[sjapps]

So I've gone down the path that everyone here probably has. I was looking at ChangeNotifier and started implementing. Awesome idea and awesome library. As your models grow, you begin to realize that you are updating the whole model with the smallest changes. Then you do some googling and find this awesome library (thank you). But then you run into this blocker because your code is passing in multiple providers (since you like to think seperation of concern and have providers broken down).

IMO it is okay to depend on the provider package. Any medium size project will probably use that in some ways. As long as we can contain the import, I think we should be fine.

[stukdev]

The same for me, now i'm blocked because i can't use with MultipleProvider.

[saarangtiwari]

Any updates on this issue as I am also stuck because of not being able to use MultipleProvider?