There are many versions of implementation of BLoC pattern. One of them is flutter_bloc by Felix Angelov.
On one of the social medias I came across of the statement that flutter_bloc
is not a good choice for the project and another BLoC or another state management should be chosen instead .
Actually it was a small standard project separated into layers:domain,application,infrastructure and presentation. Nothing special about it.
So the guy who complained about the wrong choice was saying that flutter_bloc:
- hides implementation details
- retains a state object (why, if it is truely functional then you wouldn’t do this),
- implies a preferred way of using
mapToState– to use
asyncgenerator rather than streams
If someone could elaborate on this statement and list the real disadvantages of using flutter_bloc I would be very grateful. For example for me point 1) hides implementation details is an advantage because I do not have to deal direcly with RxDart. But maybe I am missing something. I do not get point 2 completely.
flutter_bloc works by explicitly mapping inputs to states and cannot work otherwise.
I suppose that by "Retains a state object" your friend is meaning that anyone who listens to che BLoC’s instance state at any moment will get back the same state which is the same thing you get by using
My very personal opinion about
flutter_bloc is that it can be too limiting in complex scenarios because it allows creating
BLoCs that deal only one input and one output.
Let me show you the typical example I bring to the table when talking about this.
Suppose you have a page with a carousel on the top half of the screen with some cards (let’s say those are debit cards).
The second half of the screen shows a label with the current balance of the card and a list of payments made with that card.
Let’s say that you need to retrieve these two different pieces of information from two different apis with very different response times (the balance will be far faster than the payments list).
For this situation I’d use one
streamfor cards list
sinkfor card selection
streamfor payments list
When scrolling the carousel, you sink the selected card, then the two widgets (balance and list) will listen to their own streams and update accordingly to the info loading state and data.
If you wanted to do the same thing using flutter_bloc you’d have to split this in three different
BLoCs for sure:
BLoCto serve the cards list
BLoCthat has a card as an input and the balance as an output state
BLoCthat has a card as an input and the payments list as an output state
We can surely talk about having three separate
BLoCs for the three different information for single responsibility and testability reasons, but (again, this is my very, very personal opinion) in some cases I think it would be better to wrap stuff for the same page/feature within the same
Plus, in some cases (not this), you’d have to perform a
BLoC communication, which means having
BLoCs depending from other
BLoCs (which kinda scares me in some situations)
I like to structure my
BLoCs grouping them per feature.
In the case above, these are all things relative to debit cards information screen, and if I need to navigate to some details I can do so keeping all my logic centralised into one
If a BLoC has a part of features that can be common across other
BLoCs I’ll extract them in a generalised
BLoC and go with the
BLoC communication (like this).
Note that since using
flutter_bloc forces you to have multiple
BLoCs even when it might not be necessary, you’ll have higher changes of having to perform a
Again, we can say this answer might be biased, since it stars some personal opinions of mine, so take it as a bunch of considerations and not as "law". I’d be happy to receive some feedback from whoever disagrees with me, because my
BLoC philosophy is still progressing and I’m often conflicted about what can be the best approach!
Answered By – magicleon94
Answer Checked By – Cary Denson (FlutterFixes Admin)