So I am reading through Bloc for state management for flutter.
Since Bloc allows you to sink and stream (rebuilding a widget based on the input), then is it possible to build an app mostly with stateless widgets?
As an example, let say I make lots of single stateless class widgets, thus almost everything is compartmentalized into its own stateless widget.
With the Bloc state management, I could simply rebuild a certain stateless child widget to reflect the change.
In this approach, I don't see the need of using the stateful widget. Of course, being a total beginner in flutter, I wanted to hear if this approach has any merit to it.
Is this a good approach? Any info will be much appreciated.
You're right that you can use only StatelessWidgets. You just need to be cognizant of where you create your bloc. Some ways of instantiation are more easily testable than others, like passing the bloc to your StatelessWidget as an argument.
But for implementation, I like the flutter_bloc library the best:
https://pub.dev/packages/flutter_bloc
It includes BlocProvider which automatically handles creation and disposal of blocs.
One other thing to note is that you'll often have to kick off an event in a bloc to perform some action and a StatefulWidget could be useful to run that in the initState method.
You could either say in a StatefulWidget:
initState(){
_myBloc = SomeBloc()..add(SomeEvent());
}
// Then somewhere in your widget tree
BlocProvider<MyBloc>(
create: (context) => _myBloc,
builder: (context, state) {},
)
OR, in your StatelessWidget:
BlocProvider<MyBloc>(
create: (context) => MyBloc()..add(SomeEvent()),
builder: (context, state) {},
)
You'll find what works best for you, but I've found with Flutter that it mostly depends on the situation and goal of a particular feature. There's no need to pin yourself into a habit of always needing to use a StatelessWidget, but you are right that it is possible.
You can use only Stateless Widget. But there is one problem that you should close streams before the app is disposed of. It can be handled in two ways:
First, you can use a Stateful widget and close streams of bloc in the dispose method of stateful.
Using BlocProvider. In this case, Bloc Provider is a Stateful widget only. It closes streams automatically. Then you can use bloc using BlocProvider in Stateless Widget.
But it doesn't mean that we don't need stateful widgets. Stateful widgets are important in animation for example. Animation, text input or any local changes in the widget itself shouldn't be handled in bloc or other state management. it is the duty of widget itself.
Related
Maybe I don't understand the purpose of BloC or Provider but I'm confused as to why we would ever want to use them instead of using Flutter's built-in state management using the Stateful widget. I've just finished an app and can't remember a point where I wished I needed something more than the defaults. Can anyone clear things up for me?
There are a few reasons to use a BloC or Provider rather than Flutter's built-in setState:
BloC and Provider offer a more robust way to manage state.
BloC and Provider make it easier to update state across multiple widgets.
BloC and Provider can be used to manage async data.
BloC and Provider offer a more modular way to structure your code.
There are some case that you need BLoC to make you easier to define each state or condition that happening inside the application.
We will start discussing creating app like https://www.tokopedia.com/ (inspect element and go with phone size preview). You will see that between widget section tokopedia_ss there are some loading animations, and when the data load complete the widget loading animation changed to viewable widget (as user).
in bloc, you will make stateLoading(), stateComplete(data), stateFailed(data). and in the controller or screen you can describe what will happen when bloc state is stateLoading etc...
Creating this case with setstate is more complicated and make your code messy, also setstate will make phone render all the Build() code. not like BloC builder, you can define each widget or section.
So, when there are 10 sections, using Bloc you able to make it render each state but when using standard setstate it will render all the 10 sections in one time every state changes.
More information about BloC: article_about_BloC
I have one ParentWidget having two child widget.
I want to pass some callback action from FirstChild() to SecondChild() Widget without rebuild ParentWidget()like setState((){}).
I want to do because ParentWidget() has many widget. And this callback action continuously happen.
And continuously setState((){}) is not viable option for ParentWidget()
For example
setState((){}) call from FirstChild() than I want to rebuild SecondChild() without rebuild ParentWidget()
StatefulWidget is only useful in very simple business logic cases. I highly recommend that you have a look at Riverpod, where you can access a "state" from any widget, regardless of who its parent widget is. And because of how Riverpod is designed, it will not trigger any unnecessary rebuilds.
Sticking with StatefulWidget, you will need to use something like InheritedWidget as a parent of both widgets, and then have them both access it.
You can get help with state management solutions like Provider or Riverpod.
I may write an example code if you use Riverpod, but generally speaking, in such case, you need to place the state outside the Parent widget into some external variable. Then you can access and share it between both Children without rebuilding Parent.
I'm Searching a lot about the Difference between Inherited Widget and Bloc State management
I found that Inherited Widget is immutable but Bloc don't
I know the mutable and Immutable concept well but I just want to ask
Why inherited widget is Immutable and what difference between it and Bloc ?
Bloc and inheritedWidget are very different things.
Bloc is component that takes events as an input, react to this event and yields state through stream. Widgets then can listen to this stream of events and rebuild when new pierce of data is available. Bloc Is independent of widgets that listen to it, or insert events.
Inherited Widget just provides piece of data down to all his children. You have access to this data through buildContext. Also you can notify inherited Widget that Its data changed, which will result in rebuilding all widgets under it.
I sometimes see stateful widget with the state which doesn't have any state fields. What is the reason of using such stateful widget? Is not better in that case to convert that stateful widget into stateless widget?
State objects (created by StatefulWidget) have their own lifecycle. They can override initState, didChangeDependencies, didUpdateWidget, dispose, etc to perform some tasks at specific cases. See lifecycle description in State class docs
While using BLoC in flutter, whats the difference between defining the BlocBuilder / BlocListener in A Stateful widgets vs a Stateless widget ?
Can't we always use Stateless widgets as bloc takes care of rebuilding the widget for us ? Are there any usecases where you might want to use a Stateful widget instead ?
PS : I am experimenting with the flutter_bloc 1.0.0 package for flutter (https://pub.dev/packages/flutter_bloc).
You can use stateless weights throughout the app as any rebuilding can be handled by the builder methods in StreamBuilder or BlocBuilder. There is no requirement to do so, though it is generally recommended, but it might make sense to make some small widget stateful if you want a click to toggle some information or display the button that interacts with the bloc.