Pass a closure ussing 'ref' to an object returned by a Provider

[wujek-srujek]

I have a providerA (StateNotiferProvider returning NotifierA) which is used by providerB (StateNotifierProvider returning NotifierB). When a certain method of NotifierB is called, it should get some data from the state of NotifierA. In my implementation, when NotifierB is created it is given a callback (I don't want to pass the whole NotifierA, for reasons) which is invoked when NotifierB.doIt is called. This callback reads NotifierA using providerA and returns the value of StateA.fieldFromStateA, which is further used by the method NotifierB.doIt.

The code:

final providerA = StateNotifierProvider<NotifierA, StateA>(
  (ref) => NotifierA(),
);

final providerB = StateNotifierProvider<NotifierB, StateB>(
  (ref) => NotifierB(() => ref.read(providerA).fieldFromStateA),
);

It works great as far as I can tell. My question is whether it is safe to give another object a closure which captures ref and uses ref.read (or any other method, actually)? I suppose the ref instance (aProviderBaseRef or its subclass) won't change if NotifierA changes and providerA emits a new one, and the read method will still work correctly?

Judging by the docs https://riverpod.dev/docs/concepts/combining_providers/#can-i-read-a-provider-without-listening-to-it it should be just fine, but this docs is for 0.14.x and I'm using 1.0.0-dev.x and maybe things changed?

[rrousselGit]

This is fine. Although I would recommend passing ref itself, so that NotifierB can call ref.read(providerA)

[wujek-srujek]

Is there any particular reason?

My reasoning: I don't want NotifierB to depend on Riverpod (which it would because it would compile against Riverpod types, like ProviderBaseRef). When I pass a callback it is not, it doesn't need to know anything about Riverpod. And as it is just a callback, it will make testing easier - I won't have to deal with ref etc. in tests of NotifierB, I will just pass a dummy callback. In general, I don't like to make my code depend on frameworks if I can help it, and it is trivial in this case.

[rrousselGit]

The provider and StateNotifier are voluntarily tightly coupled, and the barrier between them exists only because of language limitations.
As the language evolve, a provider and its StateNotifier will fuse into a single entity.

Trying to separate them doesn't make sense. It's only making things more complex for no reason

[wujek-srujek]

There are so many reasons to not do it like you say if the other way works just as well, let my give you a few.

For now state_notifier and riverpod are separate libs so I can use state_notifier without riverpod, and I might want to do it. E.g. if I decide to migrate away and use a different lib, I won't have to deal with riverpod in NotifierB. As far as I know they are not tightly coupled either - only riverpod is tightly coupled to state_notifier, but not the other way round - please correct me if I'm wrong, but I think I'm not as this would create a dependency cycle.

The code is not more complex, in my opinion it is actually simpler and makes testing simpler, as NotifierB doesn't need to know anything about Riverpod or ProviderBaseRefs etc. I don't want NotifierB to look up anything itself, I want it to just call a simple function and get one piece of data. (This might change if NotifierB would need to look up a lot of things, then passing ref could make sense, but I would also argue it could be broken design because this class could be doing too much and couple to too many things.)

I don't want to couple classes to other classes if this is not necessary, even if I couple them to some other classes from the same lib (which actually isn't the case here, as mentioned above) - less coupling is better, makes code more manageable and easier to reason about.

Then there is the case of SOLID and I - I don't want to even see methods that I don't care about in NotifierB: watch, listen, whatever else comes with ref. I don't want anybody using these methods there - and if they don't get ref they won't be able to.

You say it doesn't make sense, I say it does. We are also getting off-topic here: you said my example from the first post is safe to use, I couldn't be happier.