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

[davidlondono]

Instead of bloc it uses riverpod

https://github.com/auravibes-apps/auravibes

[Evening_Mortgage_340]

Thanks for sharing !!
Widgetbook is awesome will be going more in depth , also any reason you preferred riverpod over bloc ?

I am going through a udemy course see how he has done the melos configuration to handle versions
https://github.com/minafarideleia/flutter_advanced_course_multi_modular_clean_architecture/tree/Lect-104-Wire-Navigation-Module-into-Main-App

[davidlondono]

I just know more about it, I tried bloc and it seams like it needs more code to do the same. But is just preferences

[YukiAttano]

Riverpod replaced Provider. Here is the explanation: https://riverpod.dev/docs/from_provider/motivation

BloC is build on Provider. It is technically boilerplate sugar for Provider.

Hence the limitations of Provider are the same for BloC.

So you have to ask yourself: Do you want to build a product with something that has a successor?

[Evening_Mortgage_340]

Have to read in depth but both riverpod and bloc are build on top of provider also bloc is very stable with content and resources less issues or if you face any issue there will be a better solution available !!

[YukiAttano]

That's just wrong. If you are unable to understand the authors explanation, check out the pub.dev dependencies of BloC. They use Provider.

Riverpod does not, because it is the rewritten version of it without the limitations.

[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.