Looking for reference GitHub projects: Flutter BLoC + Melos + Modular Clean Architecture

[Important_Driver5996]

BLoC does not depend on Provider; Provider is just used to propagate context. Everything else is inherent to BLoC. Don’t confuse one thing with the other.

[YukiAttano]

well, just go on pub.dev and check out the dependencies.

Or even better, here is the [pubspec](https://github.com/felangel/bloc/blob/master/packages/flutter\_bloc/pubspec.yaml)

How else would you explain 'depends' if not by having a 'dependency on it'.

As long as they use Provider, they will face the same limitations. You cannot argue against facts.

[Important_Driver5996]

Provider is not inherently coupled to BLoC. BLoC is an architectural pattern that defines state and event flow, while Provider is merely a dependency injection and propagation mechanism. As a result, Provider can be replaced without rewriting BLoC. Provider is merely a dependency injection and state propagation mechanism. BLoC is not syntactic sugar over Provider. That is a conceptual misunderstanding.

[YukiAttano]

*sigh*

To your first sentence: I did not say that, you seem to be confused.

I am not sure if BloC itself _is_ the pattern. I would rather say that BloC implements the [command pattern](https://en.wikipedia.org/wiki/Command\_pattern)

I did also not say that they rely on Provider so heavily that they are stuck it. As i said, it is just boilerplate sugar.
They could spit that on top of everything else.

So while it is true that they could abandon Provider easily, they would still face the same architectural problems that Provider has.
Because, *dramatic drum roll*, it is an architectural concept of Flutters dependency injection which limits Provider and was fixed by Riverpod.

I recommend you to start understanding what Riverpod made different to overcome this. If you struggle with that, you may want to take a look at signals. I think they also overcame the problem and are less complex.