Why is it a bad practice to use read inside the body of a provider?

[julienlebren]

I wonder why is it a bad practice to use read inside the body of a provider.
In some cases, it's useful to read a provider without listen to its changes BUT it's not possible to pass ref.read as a parameter.
Since I'm a bad boy, I tried to use ref.read inside the body of a provider 😇
Whereas it's not recommended, it worked. But I would like to respect the documentation 😅
So my question is: could you briefly explain why it's not recommended?

[rrousselGit]

👋

There is an explanation here #321 (comment)

[julienlebren]

Thank you, I searched in the discussions before asking but not in the issues since it's not really an issue 🙏🏻

[rrousselGit]

No worries

Note that this may change with the V1

With the addition of WidgetReference, I'm thinking of having ref.read "maintain the state of providers" without causing rebuilds.

[julienlebren]

In some cases, we need to read a provider just once without maintaining its state.
For example, in the use case which lead me to open this discussion, I just need to read my object in order to open a form to edit the object.
But I don't want this form to rebuild if the object is updated elsewhere (which is something possible with Firestore real time updates).
That's why using ref.read in the body of the provider was the best solution... before I read that you don't recommend this 😅
I currently figured this out by using a ScopedProvider when opening the form.