I have an application which required the writing of many blocs.
Several pages use the same bloc. For example, messaging pages use the MessagingBloc.
Currently, I use a global multi-provider to dispatch blocs to child widgets. The problem is: when I change pages (so I no longer use the messaging feature), the bloc is, logically, still present in the tree structure.
Do you know a way to have in the tree, only the blocs that are currently in use? (maybe working with one Navigator by feature but it seems too complicated/expensive)
Related
I've been coding with dart and flutter for over a month now, one thing that I was recommended to do by my friend is to learn Bloc as it would be helpful for big projects for businesses. From watching Videos on Youtube, reading documentations on it and also looking at Github repo's I've still not understood why we need to use Bloc and its features (FYI: I've only started using Bloc the last 2 days') Would appreciate if someone would explain what's the purpose of using Bloc as opposed to just normally coding.
Benefits of using Bloc pattern
It follows SOLID principle.
Your business logic is decoupled from the UI.
You can use same Bloc object in various screens. For example if you are developing e-commerce app, you might want to show cart icon with items added on many screens and items could be added to cart from any screen, you don't have to pass around Cart object or Function to addToCart.
You instantly get notified when Bloc state is changed and you can build your widget based on new state. This also handles unnecessary builds.
You can change any implementation of business logic (like form validation) in the bloc and your UI will not need any change.
Adding Analytics to the app is also convenient.
Less logic in Widget classes means easier readability.
You can transform events passed to Bloc. (in case if you are showing search bar and on every letter type, you are making a network call to show search suggestion, you can add debounce to certain time).
You don't have to check for Authentication in every screen.
You can respond independently to various state changes of Bloc for showing Snackbar/Toast in any screen.
Less number of items passed while creating widget class (as many properties can be accessed from Bloc object)
Follows MVVM pattern which says model, viewmodel and view should be independent of each other so that future modifications/ scaling/ debugging is easier.
There could be many more benefits which others can tell. You will only realize them once you would have started using the Bloc after working with a project which does not have state management.
Sidenote: flutter_bloc library is an option to implement Bloc pattern. Bloc pattern was showcased by Google and you can write your own implementation as well. But the flutter_bloc library is very robust.
BLoC or any state management protocol will only help you to separate data and presentation layer in your project. It will prove useful when a company has to grow its tech team or if they are planning to separate front-end and back-end development.
I am currently learning to use the BLoC pattern for state management and architecture for Flutter and Dart.
I have come across 2 ways of providing access to a BLoC in a widget.
1 - Use BLoCProvider or BLoCProvider.value when accessing a widget and passing it to another screen.
2 - Wrap your MaterialApp widget in a BLoCProvider to provide access to a bloc globally.
It seems that using the 2nd option would always be easiest - a single place to manage your BLoCs, no issues with build context referencing, ensuring a single BLoC instance, and allowing global access!
Are there any drawbacks to creating and providing all an applications BLoCs in this way? Are there any performance issues, etc?
I answered this briefly in another question yesterday.
In short:
blocs that need to be globally accessible should of course be. This could e.g. be a bloc that is handling authentication or notifications...
other blocs should not be globally accessible, this could e.g. be a bloc that handles fetching information from a backend service etc. I'd love to hear any good reasoning why a screen far down a widget tree that handles something special should have it's bloc globally accessible that any other widget could access...
Having all blocs accessible globally can have a negative effect on performance and it would break common good programming practices.
Edit:
This is from the creator (Felix Angelov) of flutter bloc:
The main disadvantages of providing all blocs globally are:
The blocs are never closed so they are consuming resources even if they aren't being used by the current widget tree
The blocs can be accessed from anywhere even if the state of the bloc is scoped to just a particular feature
The blocs typically end up needing some sort of "reset" event to revert back to the initial state which is not necessary if they are
properly scoped and automatically disposed by BlocProvider
My recommendation is to create a bloc per feature and provide that
bloc only to the specific subtree that needs it. Hope that helps
I'm relatively new to Flutter and Cubit pattern and I'm trying to figure out which are the best ways to work with them. Recently my colleague and I have been struggling to reach an agreement where we should inject the cubit and the repositories.
Reading the bloc/cubit documentation, it is not very clear about where we should do it.
IMO, everything that we need to instantiate, should be injected as high in the tree as possible where two different components that will use this information have in common.
For my colleague, each widget can instantiate one cubit, meaning that each widget will have its own instance of the cubit.
I would like to discuss about what are the community thoughts and best practices regarding the dependency injection and architecture regarding cubit.
There is no single answer to that question. It all depends on your project structure and architecture. In general though:
It's OK to create a few cubits/blocs in one screen/widget. Some widgets or screens contain more than one business logic stuff. Cubits are just classes that help you maintain the state, but it's no different than having many animation controllers or text editing controllers, it's just that it serves a more high-level state management. Let's say that you have a comments section in your app. You may have:
a cubit for the comments themselves, to load them, load more on scroll, report error when loading failed etc.
a cubit for each comment that manages the "Like" button under a comment
It's perfectly valid to have it that way.
It's OK to have global cubits for the whole app. There are some things that you need to have access to from the whole application. It usually is navigation (Navigator), and some theme management (Theme), why not something more business-logic related then, like authentication logic, current user context, user's app preferences, etc.? :)
IMO, everything that we need to instantiate, should be injected as high in the tree as possible where two different components that will use this information have in common.
This is a good approach. Most frequently it will be above your routes, so somewhere above your MaterialApp. If you make use of nested Navigators, then this common place could be above this nested Navigator.
On a more technical side, how will you manage the dependencies used in those cubits/blocs is up to you and your liking. I find some of the options:
Instantiating all repositories and other dependencies in main.dart method and then passing them in constructors to your blocs/cubits in Providers.
To reload those dependencies you will need a Hot Restart though, Hot Reload won't be enough.
Putting your dependencies in the widget's tree with Provider, just like blocs/cubits.
Using riverpod instead of provider.
Using a Service Locator pattern with get_it and injectable combo.
The most correct choice will be something that you (and your colleagues) are most comfortable developing with and that scales well.
Ok so I have a running to app, with a bunch blocs along the way going down the tree.
I have a page that is opened by a notification and I'd like processes in that page to update some of those blocs.
with something like redux it'd probably be easy with a "single source of truth" you can access anywhere.
how can I accomplish that.
You can have that in bloc with cache initialising bloc objects.
But in case you want same bloc instance object in various routes, you will have to Provide them before your navigator (which is typically MaterialApp widget.)
I use the provider package to manage my application state. I have a few questions concerning how to manage the state in the application.
Is it a good practice to create a ChangeNotifier class for each screen in my application to handle the back end for this page (which is provided to only this screen) ?
In an example like this:
If i have a page that have multiple widgets and i need to rebuild a small part of the page like adding a new TextField on enabling a switch.
in the previous example
Should i use a provider to only rebuild the small part of the page or this part is mostly handled by only using changeState() ?
in case that the local-state of the page should be handled in the screen.
Where should i place the logic of the page, like http requests on button clicks and loading data for this page ?
If the state that you are updating is only needed within one widget with one or two down widgets down the tree, I would recommend using the built-in SetState. While both Provider and SetState would work for any form of state management, I tend to think of Provider as similar to React Context.
Provider is great for holding state at page levels or if you want to maintain the separation between widget builds and logic in different files.
SetState is great for local widgets with not a lot of nested widgets underneath.
Here is a great article that discusses the different state management solution approaches. At the end of the day, it's up to preference!