You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 28, 2024. It is now read-only.
Repository navigation
This repository was archived by the owner on Oct 28, 2024. It is now read-only.
guys nice project but after I review the code its seems like its not fully bloc.
for example usermanager.. the programming community past the period of "managers" and also use it as a global listener and singleton its not good idea.
Hey! Thanks for the feedback. I guess we couldn't easily let go of them managers... Also, when we started flutter we couldn't decide what state management tool to use so we resorted to singleton managers.
After some time, we started using Bloc for the UI layer of the app only and high-level services, like managers and repositories, for the domain layer. Our goal was to keep frameworks and external state management tools out of the domain layer because of the complexity that comes with it - library updates, maintenance, learning curve, features from the framework that we don't need, etc. We just didn't need a state management tool for that. This may be a strong personal opinion of mine, but I find it cleaner this way.
Also, not that it ever happens, but I want to be able to easily translate my domain code to another platform, like a native app in Kotlin or Swift, and not depend on a framework that doesn't fit there.
As for the singleton pattern, we agree, it's a bad practice that we cling onto. However, our code pattern is not very different from the example you provided. We also have Repositories, but they don't provide change listeners so we wrap them in Mangers that provide listeners and also some features/use-cases that would go in a bloc.
So, Bloc is great, but I guess we just didn't want to embed a framework in our app's core.
Activity
dimitar-zabaznoski commentedon Feb 7, 2022
Hey! Thanks for the feedback. I guess we couldn't easily let go of them managers... Also, when we started flutter we couldn't decide what state management tool to use so we resorted to singleton managers.
After some time, we started using Bloc for the UI layer of the app only and high-level services, like managers and repositories, for the domain layer. Our goal was to keep frameworks and external state management tools out of the domain layer because of the complexity that comes with it - library updates, maintenance, learning curve, features from the framework that we don't need, etc. We just didn't need a state management tool for that. This may be a strong personal opinion of mine, but I find it cleaner this way.
Also, not that it ever happens, but I want to be able to easily translate my domain code to another platform, like a native app in Kotlin or Swift, and not depend on a framework that doesn't fit there.
As for the singleton pattern, we agree, it's a bad practice that we cling onto. However, our code pattern is not very different from the example you provided. We also have Repositories, but they don't provide change listeners so we wrap them in Mangers that provide listeners and also some features/use-cases that would go in a bloc.
So, Bloc is great, but I guess we just didn't want to embed a framework in our app's core.