Allow HTML templates without requiring Polymer.Element registration

[marcushellberg]

I want to be able to create an HTML template with data binding, without having to define a full-blown Polymer element with all its boilerplate. This should be an alternative to the current way of always requiring a full element.

I think that this would simplify a majority of use cases. It would also make the choice of doing mixed client/server development more explicit.

Enabling HTML templates without Polymer boilerplate would also make migrating to Polymer 3 easier, as no end user code is explicitly using it.

Mockup code for how I would like this to work:

MyElement.java:

@Tag("my-element")
@HtmlTemplate("my-element.html")
@PolymerImport("vaadin-button")
class MyElement extends PolymerTemplate<MyElement.Model> {
  private int buttonClicks = 0;
  interface Model {
    void setText(String text);
  }

 @ClientDelegate
 void countClicks() {
    getModel().setText(String.format("You have clicked %d times!", ++buttonClicks);
  }
}

my-element.html. Only the content of the <template> tag, Flow would take care of actually wrapping this up in a custom element.

<vaadin-button on-click="countClicks">Click me</vaadin-button>
<div>[[text]]</div>

I'm not sure how template dependencies should be handled. Here, I mocked it with @PolymerImport().

[jojule]

If Flow in any case reads through the HTML template (as it must), it can surely scan for custom elements used and auto-import them. (@PolymerImport("vaadin-button") did not add more info than what is already visible from the HTML)

[Legioth]

We can even go slightly further without introducing very much additional magic:

• The values for @Tag and @HtmlTemplate can by default be derived from the class name.
• @PolymerImport can in many cases be derived from the contents of the the actual template file, even though there are some tricky cases:
  • <vaadin-password-field> should import vaadin-text-field/vaadin-password-field.html
  • Distinguishing between external elements that are in bower_components and the application's own elements that would be outside bower_components.
  • Built-in Polymer elements such as <dom-repeat> that don't need any special import (even though it doesn't really hurt to import lib/elements/dom-repeat.html)

Some other observations:

• Templates implemented in this way wouldn't work without Flow, thus reducing reusability and potentially making it slightly harder for pure front-end developers to contribute to an application.
• It is possible to take this yet one step further and use <dom-bind> instead of <dom-module>, thus further simplifying things by not registering a custom element and not wrapping the contents in a shadow root.
• Where should I put any JS that I want to use, i.e. if I want to do some client-side checks before passing a message to the server or if I want to define a computed property?
• Template files implemented in this way should not by themselves be served as static files. This means that they would logically belong on the classpath instead of in e.g. src/main/webapp. This does on the other hand mean that the file would have to be moved to a different location in the file system if you would for any reason want to "upgrade" it to a standalone template.
• One open design question is whether templates made in this way should be loaded as a HTML import and thus also included when creating a bundle for production use, or if the template string should instead be included in the the same UIDL message that adds the component to the DOM and dynamically injected into the Polymer runtime.
• Production mode bundling would have to take any inferred dependency imports into account.
• This scheme might complicate things for Designer since it would potentially have to replicate some of the things that would be handled by Flow instead of just using vanilla Polymer features.

[knoobie]

I would consider this as an actual replacement for CustomLayout. (thumbs up)