Practical use of RepositoryProvider in Flutter_bloc

Question

**I'm trying to understand the use of RepositoryProvider and all i got to know is :

BlocProvider provides bloc to its children , whereas RepositoryProvider provides repository to its children

But i am still a bit confused about the practical use of RepositoryProvider. Could someone help clarify whether I understood it correctly or not?**

Suppose I want to use flutter_bloc in a weather app. When the user triggers an event to get the weather for a particular location, my understanding is that instead of fetching data directly from the API within the bloc class, we would trigger (or call) a method from our bloc class to the method in repository class. Based on the result obtained, we'll then update the state.

Is this the correct usage of RepositoryProvider in this scenario? or can somebody provide a simple scenario to implement the RepositoryProvider? Any insights would be greatly appreciated!"

Also if somebody could provide a simple yet detailed example of how to use 'repositoryprovider' in a weatherapp and what issues would it be simplifying.

Answer 1

Problem you have is common amongst people learning flutter_bloc, I had it myself aswell.

Contrary to BlocProvider, RepositoryProvider can provide object any type instead of, simply put, Bloc type only. You can see this in source code:

class BlocProvider<T extends StateStreamableSource<Object?>> 
    extends SingleChildStatelessWidget ...

class RepositoryProvider<T> extends Provider<T> ...

Idea was that maybe some people would like to provide and access repositories the same way that flutter_bloc provides blocs to its widgets, by implementing provider design pattern. In reality, this is in my observation almost never used, because people choose to separate views layer from business logic and data layer, so that it's never required (or even avoided) to have access to these repositories from widget level and if they need that possibility, they use service locators and dependency injection like registering these repositories using get_it because it works better for them.

It was used in example mentioned by you mainly because documentation tries to cover all possibilities of tools the package can offer, but it doesn't mean that it is the best solution to that problem. Although it is valid solution I don't think it's the most efficient one.

Most of the time all calls to repository should be triggered by blocs only, so that need of having access to repositories from views layer (f.e. build methods) disappears.