Riverpod problem with instantiating multiple providers of same type

[Vishnukumardev]

This is more about a theoretical discussion of flutter riverpod state management package. Currently I am trying to migrate one kinda huge project from Provider to Riverpod and I encountered an issue which was easily solved in Provider, but seems to be a "show stopper" for Riverpod.

So the issue is following.

Imagine that you are having a ClientDetailScreen that can be opened from multiple places of the app. The basic path to get there is ClientsTab > Search (click on searched name) > ClientDetailScreen opens. However you can also get there from a completely different tab, let's say a dashboard, where you have messages from the clients and when you click on their name, you get into the ClientDetailScreen as well. Significance of this is that there can be N of ClientDetailScreens open.

From the ClientDetailScreen you can access all kinds of subscreens that are related to this particular client with which you entered the screen. Now the issue arise.

Alright, so in order to access some information about this client across all possible subscreens with Provider package you created a ChangeNotifier on top level of ClientDetailScreen and that means every single screen had its own provider accessible. Meaning that in all subscreens and related widgets you could do: context.read(); and you would access correct data everytime.

With Riverpod, this problem does not seem to be so easily solvable. Riverpod is way more strict about creating providers. Basically they are created as soon as they are used on a global level. I know about family constructor to differentiate between correct instance, however I am hesitant to choose that path especially when it would mean I would have to somehow distribute the clientId across all the subwidgets and that just does not seem right. I am more inclined to the fact that there is something fundamentally wrong with how the app is written. I was trying to solve it via doing a local ProviderScope that would encapsulate whole ClientDetailScreen hoping that all subwidgets would then access correct provider. However for some reason, all the subscreens are pushed on the same level as ClientDetailScreen meaning that they don't access the correct scope and because of some dependencies I am unable to place the ProviderScope even higher.

Have you ever solved similar problem? Thanks for any response.

link:https://stackoverflow.com/questions/79138726/riverpod-problem-with-instantiating-multiple-providers-of-same-type

the above link represents the whole situation of this scenario. Please read it carefully. He also mentioned a solution. But it seems to be a work around.

[rrousselGit]

I know about family constructor to differentiate between correct instance, however I am hesitant to choose that path especially when it would mean I would have to somehow distribute the clientId across all the subwidgets and that just does not seem right

That is 100% the right solution.

This is the official solution to this problem in Riverpod. If you want N state from one provider, you use a family.

Scopes are not the recommended solution. They are here for different reasons

[Vishnukumardev]

@rrousselGit Thanks for you reply ,sir . I need to ask one favor from you. I wish to contribute to this project .But my skill set aren't enough for contributing to this project. I am an entry level Flutter Developer now . can you tell me what i want to learn in order to contribute to this project