Best Practice Question: BlocProvider Placement?

Help General
1

Where do you usually place your BlocProvider?

:one: above the Scaffold?

:two: I nside the body of the widget?

And why? :thinking:

2

With BlocProvider, BlocBuilder, BlocConsumer you should place it above where it’s needed. You should avoid unnecessary rebuilds, and unnecessary tree traversal.

3

ok, i use it above the body just and if i have any changes in the appbar or floating action button
it will make the blocProvider above all scaffold so it will make any issues in performance or tree traversal ?

4

It depends on the features you are building. I typically believe there are 2 general use cases:

  1. Your bloc is a singleton. In this case, your bloc is provided near the top of the widget tree. Any widget below can consume the state. This is generally how most of my blocs operate; I’ll have a feature that has a bloc, the state of the feature shouldn’t change when navigating around the app, so the bloc is provided high up and doesn’t get disposed of.
  2. Your bloc handles state for a disposable widget. In this case, your feature is a throwaway and it’s ok to rebuild the state from scratch when needed. Your bloc is provided in the screen you’re routing to. An example of when this is useful: you have a list of objects and you want to view and operate on the details of one of those objects. The details screen gets its own bloc provider, which is initialized with the ID of the item you’re viewing. The bloc will fetch the object, allow you to mutate state, etc. When you navigate away from the details view, the bloc and its state are disposed of. This allows for fine-grained control over a single object, without holding unnecessary items (e.g., previous items you’ve viewed the details for) in memory.
1 Like
5

Best practice: don’t use BLOC at all (nor Riverpod).

1 Like
6

I wouldn’t say it as extreme but it’s worth checking alternatives. And instead of a block provider many devs just register all blocs in get_it

7

Hi All,

I am a dot net developer with more than 10 years of experience. Now, I extended my skills in Flutter. I have been learning and working on Flutter since last year.

I would like to know from the experienced and experts of Flutter that which is the best state management technique and the satisfying justification.

Thanks in advance..

8

Hey, and welcome.

This is a bit like asking “tabs vs spaces… and cite your sources.” I think you’ll get a lot of varying perspectives.

Speaking from experience, I can say this:

  1. Almost every project I’ve been involved in (either ones I’ve written myself, or ones I’ve found myself working on) have used flutter_bloc.
  2. Don’t use GetX.

I also hear Riverpod is quite a nice solution, and some day I may check it out, but somebody else would have to weigh in on that solution.

Your next question is, “why flutter_bloc?” That’s a fair question. For me, I like being able to separate my states from my events, and have my business logic be separated from both of those. I like having the clear distinction.

1 Like
9

I highly recommend checking out watch_it because it’s one of the easiest and approachable state management solutions.

OK, a bit more context to the question why do so many people use bloc. I think it was kind of a misunderstanding :slight_smile: bloc was originally designed inside google to share business logic between Angular Dart Web apps and Flutter app which is a requirement that is quite different from what most mobile apps need. But because it was presented by a member of the Flutter team, people thought it is the official recommendation from Google how to do state management. The @felangel published his very well made package and many devs just followed that path.

Currently we have three real alternatives IMHO that I would take into consideration for a bigger app:

  • obviously my own packages watch_it with get_it and flutter_command and I can only tell from the feedback I get from users switching from other packages that people really like working with it.
  • rivpod but you have to decide if you like the API its is definitely a very well maintained package with a lot of fans
  • bloc (flutter_bloc) still an option but in my opinion the least attractive one because of the amount of boilerplate code and also I personally find the pattern of pushing a message into a Stream to call a function from the UI pretty cumbersome. Felix added Cubits on top that improve that but then I ask why do we need the whole Stream infrastructure beneath at all.
1 Like