This comment was originally written by @zoechi

see also https://plus.google.com/+SethLadd/posts/VijLdhGhtzg

Set owner to @justinfagnani.
Added Type-Enhancement, Area-Polymer, Triaged labels.

I have an implementation of this based on events, so it has the potential to be framework, DI container, and maybe even language agnostic. I should be able to publish the code very soon.

The lifecycle is quite different than Angular - we can't do constructor injection, but in the constructor, read(), and enteredView() we can fire dependency request events.

Changed the title to: "Dependency Injection support for Polymer".

FYI, there was some discussion long ago about adding a second argument in document.registerElement to have an argument provider passed there as well (see https://code.google.com/p/dart/issues/detail?id=15804#c1).

True, and I've talked to Dimitri a lot about adding something like this. I've come to think that constructor injection might not be the best thing for elements though. So many dependencies are context-dependent, that being able to resolve them on enteredView() is pretty key, and we might want to encourage that over constructor injection, even if constructor injection was available.

Also, consider that for testing of elements we'll have to call the lifecycle methods anyway to ensure the element is set up (we might want to consider if there are useful helpers for element tests). Resolving dependencies outside the constructor might not actually add a lot of complexity to tests given that.

Oh, I was under the impression that we didn't wanted to do any injection that couldn't be done in constructors, to make sure DI is still easy to reason about and to make sure we can statically generate equivalent code.

Would that still be the case even if we inject on 'enteredView'?

Looking at the use cases for DI in Angular, I just don't think that we have as many fixed dependencies, and that enteredView(), or on-demand, is generally a more appropriate place to resolve a lot of these things.

Totally non-scientifically, here's what I see commonly injected in Angular:

 * Scope - we don't have this
 * Element - we have this
 * Other Directives - we don't have directives, but there is behaviors.dart. The big difference with behaviors is that they can come and go dynamically as the DOM changes, so they're not fixed. I'm thinking of other avenues for behaviors and elements to collaborate.
 * Parser and Interpolate. I'm not sure we have the same use cases, but each element already has access to its binding delegate via syntax, and other hooks like instanceTemplate()

Services are something that could be fixed and appropriate for constructor injection, but sometimes polymer services are created as custom elements themselves, which are meant to be found via the document, which could make them context dependent too.

I don't think dependencies being more dynamic effects code-generation. What we generate is the module/injector code so that it doesn't use reflection. That will still work. Also, an event-based dependency resolution system would be DI container agnostic.

In terms of reasoning about DI... well, I think we could actually make things a bit easier to understand by resolving dependencies later. Documents are mutable, and fixing some things on element creation, while others are subject to the changing document structure could lead to confusing situations.

Last thought for now: Polymer and custom elements don't speak much to how models and UI patterns like MV* are used. If you use custom elements like views, and separate out controllers, the controllers can use very standard DI.

This comment was originally written by @zoechi

This seems all very promising!

I think it could be easier for code generation to have an 'inject(Typex argx, ...)` callback method to be called by the DI container that provides the arguments listed in the method signature, just as it is normally done with the constructor.

I haven't seen how the syntax/semantic would look like the event-based approach though.

Removed Area-Polymer label.
Added Pkg-Polymer, Area-Pkg labels.

Added this to the Later milestone.
Added Priority-Low label.

Added Polymer-P-2 label.

Removed this from the Later milestone.

Removed Polymer-P-2 label.
Added Polymer-Milestone-Later label.

Removed Polymer-Milestone-Later label.
Added PolymerMilestone-Later label.

This issue has been moved to dart-archive/polymer-dart#186.