Bloc: Stateless or Stateful? App wide Bloc or Widget wide?

[enricobenedos]

Good morning,
I'm using flutter_bloc from some months also in production. Sometimes when arrives the moment to implement a new feature in my production app I collide with some structural decisions that I don't know how to deal with.
For example when I need to use a bloc on a single page (one shot), is it better to use Stateless or Stateful widget?
This is the Stateless implementation

class MyPage extends StatelessWidget {
  const MyPage({Key key}) : super(key: key);

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: BlocProvider<FavouritesBloc>(
        create: (BuildContext context) =>
            FavouritesBloc()..add(FetchFavourites()),
        child: BlocBuilder<FavouritesBloc, FavouritesState>(
          builder: (context, state) {
            return RaisedButton(
              onPressed: () =>
                  BlocProvider.of<FavouritesBloc>(context).add(AddFavourite()),
            );
          },
        ),
      ),
    );
  }
}

and this is the Stateful one

class MyPage extends StatefulWidget {
  const MyPage({Key key}) : super(key: key);

  @override
  _MyPageState createState() => _MyPageState();
}

class _MyPageState extends State<MyPage> {
  FavouritesBloc _favouritesBloc;

  @override
  void initState() {
    super.initState();

    _favouritesBloc = FavouritesBloc();
    _favouritesBloc.add(FetchFavourites());
  }

  @override
  void dispose() {
    _favouritesBloc.close();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: BlocBuilder<FavouritesBloc, FavouritesState>(
        bloc: _favouritesBloc,
        builder: (context, state) {
          return RaisedButton(
            onPressed: () => _favouritesBloc.add(AddFavourite()),
          );
        },
      ),
    );
  }
}

Considering the library documentation in the Stateless case the bloc will be disposed automatically and with this consideration I think that this one is the most preferred way if you haven't any other type of state to implement. But as my introduction question I'm not sure about that.

Another thing that I'm not able to measure and decide is when to use bloc as "app wide" bloc or single widgets bloc. For example, if my app has 5 principal pages when user can navigate and on only two I need a specific bloc, which is the best option to choose in this case? Inject bloc app wide or create and use it only on the two specific pages? This question also arises from the fact that my application already has 3 app wide bloc and I don't know if it is a performance problem.

 return MultiBlocProvider(
      providers: [
        BlocProvider<Bloc1>(create: (context) => Bloc1()),
        BlocProvider<Bloc2>(create: (context) => Bloc2()),
        BlocProvider<Bloc3>(create: (context) => Bloc3()),
      ],
      child: BlocBuilder<Bloc1,Bloc1State>(
          builder: (context, lstate) {
        return BlocBuilder<Bloc2, Bloc2State>(builder: (context, tstate) {
          return MaterialApp(
.......

I apologize in advance for any misunderstandings in my explanation

[narcodico]

Hi @enricobenedos !

Deciding between stateless or stateful has nothing to do with bloc. As you've already kinda guessed, you should always go for stateless, unless you need to deal with some additional state.
When using bloc you get all your state from the bloc itself, so you mostly deal with stateless.
You'll mostly need stateful widgets when dealing with UI specific objects like controllers or animations.

As for global blocs that's really up to you to decide based on what the bloc deals with. If it smells like global state you'll provide it globally, else scope it.
Blocs are kinda lightweight, so you shouldn't be worried about performance, especially since they're lazy loaded by default, meaning they're created only when something requests them via BlocProvider.of(...). The good thing is you can always easily move up or down the bloc in the tree.

[enricobenedos]

Thank you for you time @RollyPeres, your answer is what I was looking for.