Thoughts about Riverpod vs. DI (e.g. get_it)

[dalewking]

In a short conversation here: https://twitter.com/remi_rousselet/status/1280123649400471553?lang=en you discussed that you didn't like the idea of Provider + get_it and that Riverpod should solve that.

I am working on my first project with Riverpod and am starting to be drawn to adding something like get_it with Riverpod. The use of global variables to define the provider can actually introduce unwanted coupling. But it is perhaps hard to explain.

So I try to practice a very clean design with no unnecessary coupling. One version of clean design has the domain layer define repository interfaces. The data layer provides implementation of those interfaces. So the data layer needs to say that I need someone to provide me with an implementation of this interface, but it should in no way be coupled to who provides the implementation of the interface. So the question becomes where and how do you define the provider.

One would like to define the provider inside the domain module. So say the interface was the FooRepository, somewhere in the domain library you would like to say:

final Provider<FooRepository> fooRepositoryProvider = ...

But what do you put on the right side of that? If you reference the data module there, then you have broken clean design as the domain module cannot have any coupling to the data module. You could move that provider out of the domain library to your app, but then your domain library has a dependency on files in your app which ones again destroys the clean, uncoupled design.

One alternative I have thought about is that the domain layer declares it like this:

final Provider<FooRepository> fooRepositoryProvider = Provider((_) => throw UnimiplemenedError("No implementation provided");

And then in an initialization routine the data module says:

fooRepositoryProvider.overrideWithProvider(...);

Which works but seems awfully hacky and verbose.

The advantage of DI like in get_it is that you can have code that says I need this dependency, code that creates the implementation, and then binding code that says what implementation is bound to supplying the dependency. And there is no coupling from the needer of the dependency to the supplier of the dependency. That wiring is done in the binding code that is the only one that knows of the existence of the other.

Using global variables ties those 3 pieces into one variable and there is no separation unless you go to extreme manual methods. With DI the needer of the dependency only says I need something of this type and possibly a tag if there is more than one. Without that it is too tightly coupled.

Sure, most people are not as pedantic about such things as me and I am not sure how I am going to work around this yet, but wanted to put the thought out there. Wondering now about the possibility of creating a GetItProvider where the create function merely delegates to get_it to get the instance of the provider

[rrousselGit]

So I try to practice a very clean design with no unnecessary coupling.

I believe your problem is the opposite: You are trying to introduce unnecessary decoupling.

Providers already act as a decoupling.
There is no reason to decouple the provider from the logic that instantiates your class.

[dalewking]

Wanted to follow up on this topic and let you know that I solved this problem using late final variables. So in the domain layer my providers file just declares the providers that it needs using late final variables as in:

late final Provider<FooRepository> fooRepositoryProvider;

In the data layer I have an initialization function that gets called from main that sets the late final variable.

void dataInitialization() {
    fooRepositoryProvider = Provider((ref) => ....);
}

[rrousselGit]

Don't do that. Dynamically creating providers is anti pattern

[dalewking]

What is your basis for calling it an anti-pattern? Do you have any official references for what pattern it is an anti-pattern of.

I also fail to see how it is being created "dynamically". They are still created once, it it just that the initialization of the value is separated from the declaration of the type. It's called loose coupling which very much is a pattern that we are supposed to follow. That is what I am trying to overcome, the tight coupling of declaring how you fulfill the provider from declaring what provider is available.

I'm afraid we will have to agree to disagree, since you can't even see why what you promote is tight coupling.