Codecov Report

Merging #415 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master   #415   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files          11     11           
  Lines         179    198   +19     
=====================================
+ Hits          179    198   +19

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ebdde1e...f84a696. Read the comment docs.

These small improvements that you are adding everyday are just so enjoyable for the dev experience 👍

I don't get what the breaking change is ? 🤔
Or maybe I missed understood the breaking change concept 😁

@axellebot thanks! I'm glad you think so 😄

Regarding the breaking change, I changed the generic templating so for developers who explicitly provided the types to BlocBuilder and BlocListener, the code would no longer compile.

Old

BlocBuilder<CounterEvent, int>(...)

New

BlocBuilder<CounterBloc, int>(...)

For developers who omit these there will be no problems but it technically is still a breaking change.

@felangel I like it, I prefer the state type can be inferred with only passing the bloc type but,
seem imposible in dart. 🤔

Ho tricky ! I didn't see it ! So yeah definitely a breaking change ...
Thanks for clearing this 😊

It can be cool to inferred the state type but I guess there is no way to do so.

Did I read it correctly that you are saying that we won't have to wrap the parent widget's build method with the BlocProvider before using the bloc in a builder with this change?

Did I read it correctly that you are saying that we won't have to wrap the parent widget's build method with the BlocProvider before using the bloc in a builder with this change?

yes sir 👍

Deletions

The following deletions were made because they were primarily there for migration/routes.

Can you be more specific please 🤗

Regarding routes, moving forward, the rule of thumb should be: if multiple routes need access to the same bloc, the bloc must be provided above the routes.

In this way, how can I provide a bloc in scoped route? I don't like all above MaterialApp

@felangel thanks

Deletions

The following deletions were made because they were primarily there for migration/routes.

Can you be more specific please 🤗

Regarding routes, moving forward, the rule of thumb should be: if multiple routes need access to the same bloc, the bloc must be provided above the routes.

In this way, how can I provide a bloc in scoped route? I don't like all above MaterialApp

@felangel thanks

I removed those deletions for now until there is a proper solution in place 👍

About BlocProvider in build() method:

@override
Widget build(BuildContext context) {
  return BlocProvider(
    builder: (context) => CounterBloc(),
    child: BlocBuilder<CounterBloc, int>(
        builder: (context, state) { ... }
    ),
  );
}

I wonder could we make it shorter as well? Like this:

@override
Widget build(BuildContext context) {
  return BlocProvider<CounterBloc, int>(
    builder: (context, state) { ... }
  );
}

About BlocProvider in build() method:

@override
Widget build(BuildContext context) {
  return BlocProvider(
    builder: (context) => CounterBloc(),
    child: BlocBuilder<CounterBloc, int>(
        builder: (context, state) { ... }
    ),
  );
}

I wonder could we make it shorter as well? Like this:

@override
Widget build(BuildContext context) {
  return BlocProvider<CounterBloc, int>(
    builder: (context, state) { ... }
  );
}

@anticafe unfortunately I don't think so because you need to actually create the bloc and if it has dependencies you need to inject them.

@felangel
I think there should be a MultiBlockBuilder and MultiBlocListener

check my code it is not clean when I used a nested bloc builders

  BlocListener<ConfigEvent, ConfigState> _buildLoginBlocListener() {
    return BlocListener<ConfigEvent, ConfigState>(
      bloc: configBloc,
      listener: (BuildContext context, ConfigState state) {
        if (state is ConfigFailedState) {
          showSnackBar(state.configModel.message);
        }
      },
      child: BlocBuilder<ConfigEvent, ConfigState>(
        bloc: configBloc,
        builder: (BuildContext context, ConfigState configState) {
          return BlocListener<LoginEvent, LoginState>(
            bloc: loginBloc,
            listener: (BuildContext context, LoginState state) {
              if (state is LoginStoredState) {
                Navigator.of(context).pushReplacementNamed(PAGE_DASHBOARD);
              } else if (state is LoginFailedState) {
                showSnackBar(state.loginModel.message);
              }
            },
            child: BlocBuilder<LoginEvent, LoginState>(
                bloc: loginBloc,
                builder: (BuildContext context, LoginState loginState) {
                  return _buildLoginButton(
                      configState: configState, loginState: loginState);
                }),
          );
        },
      ),
    );
  }

@amreniouinnovent you can currently use MultiBlocListener and you can split up your widget into multiple smaller widgets or create a new bloc that combines that relevant parts of the state from configBloc and loginBloc and then use the single bloc in BlocBuilder. Hope that helps 👍

@felangel Thank you
I added MultiBlocListener and the code is much better

MultiBlocListener(
        listeners: [
          BlocListener<ConfigBloc, ConfigState>(
            listener: (BuildContext context, ConfigState state) {
              if (state is ConfigFailedState) {
                showSnackBar(state.configModel.message);
              }
            },
          ),
          BlocListener<LoginBloc, LoginState>(
            listener: (BuildContext context, LoginState state) {
              if (state is LoginStoredState) {
                Navigator.of(context).pushReplacementNamed(PAGE_DASHBOARD);
              } else if (state is LoginFailedState) {
                showSnackBar(state.loginModel.message);
              }
            },
          ),
        ],
        child: BlocBuilder<ConfigBloc, ConfigState>(
            bloc: configBloc,
            builder: (BuildContext context, ConfigState configState) {
              return BlocBuilder<LoginBloc, LoginState>(
                  bloc: loginBloc,
                  builder: (BuildContext context, LoginState loginState) {
                    return _buildLoginButton(
                        configState: configState, loginState: loginState);
                  });
            }))

@felangel I'm upgrading from 0.15.0 and there's a lot of new good things! 😃

I was thinking to follow a 2-steps process like:

1. Make my app compile and run
2. Refactor based on the new patterns

I'm wondering: is Automatic Bloc Lookup "mandatory"? I have BlocBuilder usages like this:

BlocBuilder<CounterBloc, int>(
  bloc: blocObject,
  builder: (context, state) { ... },
)

where blocObject is created "the old way" (i.e. in a StatefulWidget of my app). My tests fail with:

BlocProvider.of() called with a context that does not contain a Bloc of type CounterBloc

Shall I conclude that BlocProvider must be made aware of any bloc object my app creates?

@algodave thanks for the positive feedback! Your 2 step approach makes perfect sense and the automatic bloc lookup is not mandatory. You should definitely be able to manually provide your own bloc instance. Are you able to share a link to a sample app which illustrates the problem? Thanks!

@felangel Thank you for your prompt reply and the good news 😉

I'll provide a sample, but I'll be able to do that on Monday.

Nice video for this release
Flutter Bloc - AUTOMATIC LOOKUP - v0.20 (and Up), Updated Tutorial
https://www.youtube.com/watch?v=_vOpPuVfmiU