Comments (4)
@ksyro98 Thank you for answering this.
from bloc.
Hey, these diagrams are very different from the initial one, because there aren't two layers of Bloc
s and no Bloc
depends on another Bloc
. (That's good!)
In the two versions that you sent the main change seems to be that the ViewClientBloc
is split in two Bloc
s. I believe that whether this is a good idea or not depends on what that Bloc
does, and is not specific to the BLoC architecture.
The Single-Responsibility Principle comes to mind: "A module should be responsible to one, and only one, actor." If that Bloc
is responsible to more than one actors (user group/stakeholder group) or if there is more than one reason to change, perhaps breaking it into two is a good idea.
Which widget will depend on the Bloc
isn't that important. I think it's actually better to have a BlocBuilder
(or similar widget) lower in the widget tree to avoid unnecessary rebuilds. (And the widget that includes the BlocProvider
will depend on the Bloc
anyways.)
Creating a different module for the grouped classes has to do with your enterprise architecture. Do keep in mind that, if your grouped classes (cmp
, bloc
, repository
) are in one module and the BlocProvider
is separate from it; the module will need to expose the Bloc
which in that case will be an implementation detail. I believe that a widget which includes a BlocBuilder
and the widget UI can be adequately reused. That being said, do keep in mind that you know your enterprise's code much better than me.
from bloc.
Hey!
No this is not considered a best practice. In general you want to have one Bloc/Cubit for each feature (which usually means one Bloc per page).
For your situation, if you haven't included DataProvider
s already they might help you. You might be able to move most of the Repository
logic to the DataProvider
s and then use the Repository
as the middle layer. This is actually consistent with the Bloc architecture: https://bloclibrary.dev/architecture/
If you already have DataProvider
s defined, you might be able to use helper classes that will contain the code that is shared by more than one Blocs
from bloc.
Hello, thank you for your response.
I'd like to provide some additional details about our situation and our objectives. We have common widgets that are shared across different views and even applications. From my understanding, the preferable approach should resemble the following:
(In these diagrams, the orange components are the ones being reused).
What we have experimented with is depicted below:
In this model, blocs are still organized by feature but are utilized in multiple subwidgets that require these blocs to function correctly. This strategy facilitates the sharing of widgets between views without the need to propagate properties through numerous subcomponents.
Additionally, each component manages its own loading state based on the bloc it relies on. For instance, some components in my view that utilize the product bloc can display product details, etc., while the stock indicator might not load. This loading behavior is managed within each individual featured component.
This approach feels akin to assigning one bloc per feature, yet each feature is utilized by multiple components.
from bloc.
Related Issues (20)
- fix: expected: [<States>], actual [] when unit testing landing page cubit HOT 4
- Bad state: Cannot emit new states after calling close HOT 2
- State not update when adding a new item to the list HOT 1
- docs: replay bloc with multi bloc HOT 2
- fix: MultiBlocProvider and easy_localization library problem HOT 2
- docs: Add zh-cn translation for Bloc Concepts page HOT 1
- fix: transformer works incorrectly while registering each event separately HOT 2
- feat: Make hydrated_storage.dart:Storage.read() method async
- BlocBuilder widget not rebuilding the ui on certain states. HOT 6
- question: How do I design the architecture of A very complex desktop app HOT 3
- feat(bloc)!: add support for strongly typed errors on `Emitter.onEach`/`Emitter.forEach` HOT 2
- feat(bloc): add support for optional `StackTrace` on error handlers for `Emitter.onEach`/`Emitter.forEach` HOT 2
- feat: Add `force` to Emitter HOT 7
- feat: Privacy manifest file for iOS is missing HOT 4
- question: BlocObserver and Injectable Singletons HOT 3
- question: [flutter_todos] why don't close StreamController? HOT 1
- UI doesn't react to state changes after using Navigator.push HOT 4
- docs: Add/Change ko translation for Bloc docs
- docs: What is the best way to use riverpod with bloc for dependency injection? HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from bloc.