di: Provider with useValue doesn't accept const complex data type instances

[frankpepermans]

In beta 18, declaring a Provider with useValue currently fails in the angular transfomer if you use an instance of a complex data type.

For example, use the following setup to define a component:

class Bar {
   const Bar();
}

@Component(
    selector: 'foo',
    template: '<div></div>',
    providers: const [const Provider(DisplayOptions, useValue: const Bar())]
)
class Foo {
}

This throws Invalid argument(s): Incorrect identifier "const Bar()"

And the stack trace is:

package:angular2/src/transform/common/type_metadata_reader.dart 1357:7   _readIdentifier
package:angular2/src/transform/common/type_metadata_reader.dart 1375:12  _readValue
package:angular2/src/transform/common/type_metadata_reader.dart 1166:20  _readProvider.<fn>

[frankpepermans]

Current workaround:

use useFactory instead of useValue, and simply return the const instance in the factory method body

[matanlurey]

Could you try this:

const displayOptions = const Bar();

@Component(
    selector: 'foo',
    template: '<div></div>',
    providers: const [const Provider(DisplayOptions, useValue: displayOptions)]
)

It might be slightly less hacky. The current Angular analyzer/compiler is pretty rudimentary, but we have plans to improve it to include full package resolution. Can update on this soon.

[matanlurey]

P3 since there is a workaround.

Blocked by #48

[matanlurey]

Just an update: this is still blocked by #48. We have some early work done though towards getting the type information we need to actually resolve the value.

[matanlurey]

This is now planned for the 4.0 release.

[matanlurey]

This is now unblocked, with caveats:

• useFactory is still required when the resolved instance uses a private constructor:

class Foo {
  const Foo();
}

const Provider(Foo, useValue: const Foo()) // OK

class Bar {
  static const instance = const Bar._();

  const Bar._();
}

const Provider(Bar, useValue: Bar.instance) // NOT OK, we only see "Bar._".

This isn't something we can solve in the short-term, but it will make providers more useful for public constructors. I'll give an update when folks are able to start using this externally (initially behind a flag, and hopefully the default for 4.0.0).