For example, I have a page having functions about signIn and showing data, and they are not relative.
Should I create a Bloc to handle this page, or should I create a Bloc for sign in and another Bloc for fetching data?
Sorry if usage of word wasn’t precise.
2
Answers
Oh wow, past 2 years, so you got more skills than me 🙂 I think this doesn’t only relate to BloC but also other state management kinds. We can create only 1 or 2 & more BloCs but in general, they are just a "business logic layer". Model-View-Controller MVC or anything else, a module (a screen) ALWAYS contains at least 1 file for view UI 1 file for business logic layer.
You can create 2 BloCs and it is easy to read for this case (signIn and showing data). But if your screen gets more complicated, some special logics appear and you cannot separate them anymore, we just use 1 BloC for not over-thinking.
Overall, I prefer 1 BloC and it contains all of my business logic of my screen – Controller layer.
Using Top-Level BLoCs for Common Logic:
I’ve found that making use of BLoCs as central points for vital app logic is quite effective. These BLoCs serve as control centers for tasks that are needed in various parts of the app. For example, they can handle the shopping cart, user profiles, authentication, and connections to external services. These BLoCs are positioned at the top level, covering the entire app. When we use a cart BLoC in this way, any part of the app can smoothly interact with it. This means that adding or removing items from the cart remains consistent and straightforward across different pages.
Using Multiple BLoCs for Single Pages:
When dealing with a page that involves multiple tasks, I prefer employing multiple BLoCs. Take, for instance, a registration page where users can choose a location from a map or search for a location via Google APIs. Instead of cramming all this logic into a single BLoC, I create distinct BLoCs for each task. This approach keeps things organized and simplifies code management. To coordinate the collaboration between these BLoCs, I use BlocListeners. This not only maintains the cleanliness of the registration BLoC but also allows the location search BLoC to be utilized in different parts of the app. This helps reduce repetitive code and saves time and effort.
Learning from Experience:
At the beginning, I used to create a single BLoC for each page, as I hadn’t yet grasped the power of dependency injection and data flow. I ended up creating unnecessary states and events for a single page, all just to manage simple changes like button color or size.
However, my perspective shifted when I realized that the focus of a BLoC isn’t tied to a specific page. Instead, it’s about crafting logic that can be reused across different pages or thoughtfully separating and organizing logic in a meaningful way. This insight allowed me to create more versatile and reusable BLoCs that truly streamline my app’s structure and maintainability.