RFC: Compile-time dependency injection.

[matanlurey]

We'd like an Angular application to be able to use almost entirely compile-time dependency injection (no runtime checks or lookups). We'll need to be able to make more closed-world assertions about the state of your application and remove or deprecate parts of the API that make this impossible (and de-optimize in those cases).

The result is just a series of get() calls across your application:

class Bootstrap$Injector implements Injector {
  Foo _fooService;

  @override
  get(token) {
    switch (token) {
      case Foo: 
        return _fooService ??= new Foo();
      default: 
        return noProviderFound;
    }
  }
}

class RootComponent$View {
  RootService _rootService;

  @override
  injectorGet(token) {
    switch (token) {
      case RootService:
        return _rootService ??= new RootService();
      default:
        return super.inejctorGet(token);
    }
  }
}

Deprecated

• ReflectiveInjector: This relies on using the static Reflector to find and create arbitrary classes from previously generated factories.

Possible replacements:

• MapInjector
• Some sort of additional code generation in an @Component:

@Component(
  selector: 'comp',
)
class Comp {
  @Resolve(const [ ... ])
  set injector(Injector generated) { ... }
}

• Using bootstrap(<root component>, <providers>). We need to resolve at compile-time:

@Bootstrap(RootComponent, const [
  // Providers go here.
])
void main(Bootstrapper<RootComponent> bootstrap) {
  bootstrap();
}

• Using provide(), just T (type), or new/const Provider() (with multiple optional parameters):

  • const Provider<Foo>()
  • const Provider<Foo>.useExisting(AbstractFoo)
  • const Provider<Foo>.useClass(FooImpl)
  • const Provider<Foo>.useFactory(createFoo)
  • const Provider<Foo>.useValue(const Foo())

• Replace OpaqueToken with InjectionToken:

const baseUrl = const InjectionToken<String>(#baseUrl);

/// Now can `@Inject<String>(baseUrl)`
const Provider<String>.useValue('Hello World', token: baseUrl);

• Using Provider(multi: true). Not sure about replacement yet!

/cc @alorenzen.

[yjbanov]

remove or deprecate parts of the API that make this impossible (and de-optimize in those cases)

Sorry for pedantry, but I'm a little confused by this part. If conflicting APIs are to be removed, why the need to de-optimize in those cases if there won't be such cases any more? Did you mean "remove or de-optimize"?

return super.inejctorGet(token);

RootComponent$View is direct descendant from Object, so there's no super.injectorGet.

@Bootstrap

Why not reuse the existing @AngularEntrypoint?

[matanlurey]

No problem re-using @AngularEntrypoint :)

Sorry for pedantry, but I'm a little confused by this part. If conflicting APIs are to be removed, why the need to de-optimize in those cases if there won't be such cases any more? Did you mean "remove or de-optimize"?

Yes, I meant remove or de-optimize. Thanks!

[chalin]

Good proposal. I just have one comment about a suggested class definition for InjectionToken : see #288 (comment).

[matanlurey]

This will not be in 4.0.0, but I am looking at getting in part of the API:

• Using provide(), just T (type), or new/const Provider() (with multiple optional parameters):
  • const Provider<Foo>()
  • const Provider<Foo>.useExisting(AbstractFoo)
  • const Provider<Foo>.useClass(FooImpl)
  • const Provider<Foo>.useFactory(createFoo)
  • const Provider<Foo>.useValue(const Foo())

So I've opened #407.

[matanlurey]

Thanks everyone for your feedback. A summary of accepted ideas is now here:

https://github.com/dart-lang/angular/projects/4