flutter_bloc v0.20.0-rc

[felangel]

Status

READY

Breaking Changes

YES

Description

Automatic Bloc Lookup

Instead of having to manually do the bloc lookup for BlocBuilder and BlocListener whenever the bloc is not specified, the default behavior will be to lookup the bloc via BlocProvider automatically.

BlocBuilder Current Usage

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

BlocBuilder Updated Usage

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

BlocListener Current Usage

BlocListener(
  bloc: BlocProvider.of<CounterBloc>(context),
  listener: (int previousState, int currentState) => { ... },
)

BlocListener Updated Usage

BlocListener<CounterBloc, int>(
  listener: (previousState, currentState) => { ... },
)

BlocProvider within the same build

It is now possible to provide and access a bloc within the same build

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

Todos

• Tests
• Documentation
• Examples

Impact to Remaining Code Base

Breaking change which will be included in flutter_bloc v0.20.0

[codecov]

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

Impacted Files	Coverage Δ
...ages/flutter_bloc/lib/src/multi_bloc_listener.dart	100% <ø> (ø)	⬆️
packages/flutter_bloc/lib/src/bloc_builder.dart	100% <100%> (ø)	⬆️
packages/flutter_bloc/lib/src/bloc_listener.dart	100% <100%> (ø)	⬆️
packages/flutter_bloc/lib/src/bloc_provider.dart	100% <100%> (ø)	⬆️

---

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.

[axellebot]

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 😁

[felangel]

@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.

[basketball-ico]

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

[axellebot]

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.

[warriorCoder]

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?

[felangel]

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 👍

[basketball-ico]

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

[felangel]

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 👍

[trietbui85]

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) { ... }
  );
}

[felangel]

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.

[amreniouinnovent]

@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);
                }),
          );
        },
      ),
    );
  }

[felangel]

@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 👍

[amreniouinnovent]

@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);
                  });
            }))

[algodave]

@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?

[felangel]

@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!

[algodave]

@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.

[amreniouinnovent]

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