Make .runtimeType aware of necessary superclasses

[ChristianKleineidam]

The bloc library is very useful for structuring larger projects.

In one example it illustrates how to declare multiple providers:

    MultiBlocProvider(
      providers: [
        BlocProvider<ThemeBloc>(
          builder: (context) => ThemeBloc(),
        ),
        BlocProvider<SettingsBloc>(
          builder: (context) => SettingsBloc(),
        ),
      ],
      child: App(weatherRepository: weatherRepository),
    ),

It would be much nicer if I could write:

    MultiBlocProvider(
      blocs: [
        ThemeBloc(),
        SettingsBloc(),
      ],
      child: App(weatherRepository: weatherRepository),
    ),

Unfortunately, it seems currently impossible to write the MultiBlocProvider that takes the more concise input.

The straightforward way to write the concise MultiBlocProvider would be:

class MultiBlocProvider extends StatelessWidget{
  final Widget child;
  final List<Bloc> blocs

 MultiBlocProvider(
      Key key,
      this.child,
      this.blocs,
      )

  BlocProvider _createProvider(Bloc bloc){
    return BlocProvider<bloc.runtimeType >(
        builder: (context) => bloc,
    );
  }

  @override
  Widget build(BuildContext context) {
    return MultiProvider(
      providers: blocs.map((bloc)=>_createProvider(bloc)),
      child: child,
    );
  }
}

Currently, this doesn't work because Dart doesn't know that bloc.runtimeType happens to be a Bloc. Given that bloc is declared in the code as a Bloc it should be able for Dart to figure out that bloc's class is a subclass of Bloc and make the above code work.

[lrhn]

The requested feature here is to take an object at run-time and use its run-time type as a type parameter.

This is currently not possible. Dart separates type parameters from other values. This allows compilers to generate smaller code because they know that only types which occur as type arguments in at least one place can ever occur as type arguments. If we allow a Type object or the run-time type of an object to become a type argument, then the compiler cannot make that distinction, and may need to include more types as possible type arguments, leading to larger compiled programs.

So it's not that the run-time type is unaware of its superclasses (it is, but that's not the problem), you simply cannot use a run-time type as a type argument.

The solution is generally to introduce the types as type arguments, and retain them in objects until they are needed again. That's what the original example shows. The BlocProvider retains the type of the created element so it can be used later.

The concise example loses the information. The BlocProvider _createProvider(Bloc bloc) method statuc return type is BlocProvider<Bloc>, so it isn't obvious why returning BlocProvider<Bloc>(builder: (_) => bloc) is not sufficient. I assume it's because the Flutter framework actually checks the run-time type of the returned provider.

So, to make things shorter, I'd just introduce a helper method for building the BlocProvider:

BlocProvider<Bloc> provide<T extends Bloc>(T bloc) => BlockProvider<T>(builder: (_) => bloc);

Then your code reduces to:

MultiBlocProvider(
      providers: [
        provide(ThemeBloc()),
        provide(SettingsBlock()),
      ],
      child: App(weatherRepository: weatherRepository),
    ),

The type inference will get the static type of the argument and keep it in the created Provider.

[rrousselGit]

👋 maintainer of provider here

A more realistic solution would be constructor tear-down instead: dart-lang/sdk#10659

So that we'd able to write:

class Foo {} 

Foo Function() create Foo = #Foo;

This would allow:

MultiFooProvider([
  #MyFoo, 
  #MyBar
], child: Home())

This is strictly closer to the original, as the class should be created in a closure instead.