Bloc: BlocProvider.of null safe alternative

Created on 29 May 2020  路  5Comments  路  Source: felangel/bloc

Good Day,

Is there a null safe way to BlocProvider.of that returns null if the Bloc instance requested is not existing? Currently it throws ProviderNotFoundException which requires wrapping the statement into a try/catch block, adding a little boilerplate to the code.

Any suggestions are highly appreciated! And thank you very much for this library 馃槃

question

Most helpful comment

Hi @RollyPeres,
thank you for your help.
I was already aware that it was probably not possible to do what I wanted to do.
Your explanation confirm me that I was fighting against the cornerstones that make this library so effective.
I will try to refactor my code, If I need help I will not hesitate to open a new issue.
Thank you for your time 馃槉

All 5 comments

Hi @jensencelestial 馃憢

The point of that exception being thrown is to help you in dev mode identify that you're not correctly providing your bloc; as a side note, the exception comes from the provider package and not bloc.

You shouldn't be needing to wrap your calls to BlocProvider.of in try catch blocks since that's a safe operation as long as you're placing your blocs in the right place within the widget tree. If you're stumbling upon that exception it only means you're not properly providing your blocs.

As a conclusion, ProviderNotFoundException is a feature and we shouldn't need or care to disable it, but instead make use of it. 馃憤

Hi @jensencelestial 馃憢
Thanks for opening an issue!

As @RollyPeres pointed out this behavior comes from the provider package and you should ensure that the bloc is being provided correctly in order to address the exception rather than wrapping the .of in a try/catch.

Hope that helps 馃憤

Hey guys, sorry for the intrusion.
I'm facing with a similar problem: I have an utilities class that I reuse on different widgets of my app and one method of this class make some work based on inherited bloc state. Sometimes this work is done using ToursBloc state and sometimes I need to do this work using CustomerBloc state. Why I need to do this? Because both these blocs contains a common information that I need to make some work.
I try to give you an example to be more clear:

final customerBloc = BlocProvider.of<CustomerBloc>(context);
    if (customerBloc != null) {
      //Do work
    }
    final toursBloc = BlocProvider.of<ToursBloc>(context);
    if (toursBloc != null) {
      //Do work
    }

Sometimes this class inherit a ToursBloc and sometimes it inherits a CustomerBlocbut with the above sample the package (provider if I correctly understand) thrown an exception because one of the two blocs does not exist.

FlutterError (        BlocProvider.of() called with a context that does not contain a Bloc of type Bloc<dynamic, dynamic>.
        No ancestor could be found starting from the context that was passed to BlocProvider.of<Bloc<dynamic, dynamic>>().

        This can happen if the context you used comes from a widget above the BlocProvider.

I've tried also with this strategy but the error is the same:

    final bloc = BlocProvider.of(context);
    if (bloc is CustomerBloc) {
      //Do work
    }
    if (bloc is ToursBloc) {
      //Do work
    }

How can I retrieve a bloc not knowing the type and then cast/test it in order to use its state?

Hi @enricobenedos 馃憢

You should always know the type of blocs you're working with.
Most likely your issue comes from the current approach. Have you considered gathering all that common data and functionality into a separate bloc ? Or maybe your UI should be structured differently.

If you can't wrap your head around this feel free to share a minimal gist/repo with your feature and I'm happy to have a look 馃憤

Hi @RollyPeres,
thank you for your help.
I was already aware that it was probably not possible to do what I wanted to do.
Your explanation confirm me that I was fighting against the cornerstones that make this library so effective.
I will try to refactor my code, If I need help I will not hesitate to open a new issue.
Thank you for your time 馃槉

Was this page helpful?
0 / 5 - 0 ratings

Related issues

shawnchan2014 picture shawnchan2014  路  3Comments

wheel1992 picture wheel1992  路  3Comments

rsnider19 picture rsnider19  路  3Comments

RobPFarley picture RobPFarley  路  3Comments

hivesey picture hivesey  路  3Comments