Yeah, I heard others request something similar.

The main challenge here is that the html parser is doing the object allocation for us. Currently document.registerElement only takes a type argument for this, but there has been some discussion about adding a second argument on that can be used to supply the arguments needed for the constructor call.

Meanwhile, I've seen others follow a pattern where they add an extra polymer-element that does the injection for you. For example:

Instead of:
<my-real-tag ... >

You write:
<dependency-injected tag="my-real-tag">

where internally dependency-injected is a custom element that calls <my-real-tag>'s constructor and injects the arguments immediately afterwards. The arguments are not available right away when the .created constructor is called, but there should become available on the enteredView callback.

cc @blois.
Added Area-Polymer, Triaged labels.

The primary difficulty here is getting Dart VM and JS semantics the same- in Dart we construct a separate wrapper when elements are upgraded, but in JS the same wrapper is used in both scenarios. This means that the 'created' constructor is quite special in JS- to support DI we'd need to propagate a lot of this special-ness.

Removed Area-Polymer label.
Added Area-HTML label.
Changed the title to: "Accommodate constructor-based DI for custom elements".

Removed Area-HTML label.
Added Area-Library, Library-Html labels.

Removed Type-Defect label.
Added Type-Enhancement label.

cc @sigmundch.
Removed Priority-Unassigned label.
Added Priority-Medium label.

We're going to deprecate registerElement