[polymer] interop with polymer-element and polymer.js

[polymer] interop with polymer-element and polymer.js

* let polymer.js register polymer-element
* let polymer.js bootstrap for polymer.dart
* hook polymer-element's register, if it's a Dart class go down the Dart code path

building polymer.concat.js (debug only) requires https://github.com/Polymer/polymer-dev/pull/9

R=sigmund@google.com

Committed: https://code.google.com/p/dart/source/detail?r=33398

[Jennifer Messerly, 2014-03-06 04:39:28]

This is ready for review!

As usual, Rietveld is having issues :| ... but if the side-by-side is broken for
some files, the patch view should work.

[Jennifer Messerly, 2014-03-06 04:40:10]

Note: most of the files changed are trivial test changes. It's not as big of a
change as it looks :)

[Siggi Cherem (dart-lang), 2014-03-06 18:18:07]

This looks great!

By any chance do you have some data about the extra download size we'll have for
including polymer.js?

For now I understand we are not optimizing for the use-case where only Dart
polymer-elements are used. But if we were, would it be possible to support
having a slice of polymer.js where we only include the registration code that is
needed for polymer.dart?

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/CHANGELOG.md
File pkg/polymer/CHANGELOG.md (right):

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/CHANGELOG.md...
pkg/polymer/CHANGELOG.md:8: #### Pub version 0.10.0-dev
since we already published this version, how about adding 0.10.0-dev.2 ?

I assume when we are about to release, we'll delete the -dev entries and make
0.10.0 contain all the bullets below.

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/lib/polymer....
File pkg/polymer/lib/polymer.html (right):

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/lib/polymer....
pkg/polymer/lib/polymer.html:8: <script src="src/js/shadow_dartium.js"></script>
I guess this can't be merged into web_components/dart_support.js (this needs to
be before the polyfills, and the other needs to be after the polyfills?)

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/lib/polymer....
pkg/polymer/lib/polymer.html:9: <!--
nit: let's add an empty line above this comment.

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/lib/polymer....
pkg/polymer/lib/polymer.html:13: You can replace them with different versions if
desired, as long as the other
might be worth spelling out what other scripts your are referring to
(shadow_dartium + dart_support?)

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/lib/src/decl...
File pkg/polymer/lib/src/declaration.dart (right):

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/lib/src/decl...
pkg/polymer/lib/src/declaration.dart:443:
js.context.hasProperty('ShadowDOMPolyfill');
nit: maybe it now fits in a single line above?

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/lib/src/js/p...
File pkg/polymer/lib/src/js/polymer/CONTRIBUTING.md (right):

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/lib/src/js/p...
pkg/polymer/lib/src/js/polymer/CONTRIBUTING.md:1: # Contributing
wonder if we should copy a similar file under our project root :)

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/lib/src/js/s...
File pkg/polymer/lib/src/js/shadow_dartium.js (right):

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/lib/src/js/s...
pkg/polymer/lib/src/js/shadow_dartium.js:1: // Prevent polyfilled Shadow DOM in
Dartium
I wonder if this file should be here or in pkg/web_components/

I don't have a good ideas yet, but I wonder if we should name them similar to
each other as well. For example, instead of
 shadowdom_dartium.js & dart_support.js

we could do:
  - dartium_support.js & dart2js_support.js
  - dart_support_before.js & dart_support_after.js
  - dart_support/before.js & dart_support/after.js
  - dart_support/pre_polyfills.js & dart_support/post_polyfills.js

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/lib/src/load...
File pkg/polymer/lib/src/loader.dart (right):

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/lib/src/load...
pkg/polymer/lib/src/loader.dart:286: // TODO(jmesserly): what's going on here?
Are we getting a strange mix of
not sure I understand the TODO, what does this apply to? Or is it because of the
proto is Node check further down?

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/lib/src/load...
pkg/polymer/lib/src/loader.dart:316: proto['register'] = new
JsFunction.withThis(registerDart);
wow -- I knew you were going to do this, was just not expecting it to be done
from the Dart side. Nice.

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/test/noscrip...
File pkg/polymer/test/noscript_test.dart (left):

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/test/noscrip...
pkg/polymer/test/noscript_test.dart:33: expect(querySelector('x-a') is
PolymerElement, isTrue);
we should make sure to announce this as part of the breaking changes (maybe
include it in the CHANGELOG.md that noscript is handled by polymer.js)

[Jennifer Messerly, 2014-03-06 21:05:07]

Thanks Siggi! PTAL.

For size: it is the same as
https://github.com/Polymer/polymer/blob/master/polymer.js, or ~25KB as of this
writing.

Based on the lessons we learned in platform.js, I don't think we should try
extracting part of polymer.js.

If we want to support a "100% Dart" code path, we can do it just like we did:
port enough code in the bootstrapping path and register something to be
polymer-element. The only reason I didn't do that is testing sanity -- this way
we can be certain that polymer.js interop works, because polymer.dart in fact
requires it :). I do suspect that we will want to restore a pure-Dart code path
in the future.

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/CHANGELOG.md
File pkg/polymer/CHANGELOG.md (right):

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/CHANGELOG.md...
pkg/polymer/CHANGELOG.md:8: #### Pub version 0.10.0-dev
On 2014/03/06 18:18:08, Siggi Cherem (dart-lang) wrote:
> since we already published this version, how about adding 0.10.0-dev.2 ?
> 
> I assume when we are about to release, we'll delete the -dev entries and make
> 0.10.0 contain all the bullets below.

hmmm, good question. We published -pre.0, I didn't fix the CHANGELOG tho. It
doesn't seem like Pub displays prerelease ones:
http://pub.dartlang.org/packages/polymer ... I'm guessing that's by design. In
that case, maybe we can keep this as "-dev" and flip it to 0.10.0 after release
as a stable version?

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/lib/polymer....
File pkg/polymer/lib/polymer.html (right):

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/lib/polymer....
pkg/polymer/lib/polymer.html:8: <script src="src/js/shadow_dartium.js"></script>
On 2014/03/06 18:18:08, Siggi Cherem (dart-lang) wrote:
> I guess this can't be merged into web_components/dart_support.js (this needs
to
> be before the polyfills, and the other needs to be after the polyfills?)

yes, that's right.

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/lib/polymer....
pkg/polymer/lib/polymer.html:9: <!--
On 2014/03/06 18:18:08, Siggi Cherem (dart-lang) wrote:
> nit: let's add an empty line above this comment.

Done.

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/lib/polymer....
pkg/polymer/lib/polymer.html:13: You can replace them with different versions if
desired, as long as the other
On 2014/03/06 18:18:08, Siggi Cherem (dart-lang) wrote:
> might be worth spelling out what other scripts your are referring to
> (shadow_dartium + dart_support?)

Done.

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/lib/src/decl...
File pkg/polymer/lib/src/declaration.dart (right):

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/lib/src/decl...
pkg/polymer/lib/src/declaration.dart:443:
js.context.hasProperty('ShadowDOMPolyfill');
On 2014/03/06 18:18:08, Siggi Cherem (dart-lang) wrote:
> nit: maybe it now fits in a single line above?

uh, sure.

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/lib/src/js/p...
File pkg/polymer/lib/src/js/polymer/CONTRIBUTING.md (right):

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/lib/src/js/p...
pkg/polymer/lib/src/js/polymer/CONTRIBUTING.md:1: # Contributing
On 2014/03/06 18:18:08, Siggi Cherem (dart-lang) wrote:
> wonder if we should copy a similar file under our project root :)

fortunately it exists :)
https://code.google.com/p/dart/wiki/Contributing

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/lib/src/js/s...
File pkg/polymer/lib/src/js/shadow_dartium.js (right):

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/lib/src/js/s...
pkg/polymer/lib/src/js/shadow_dartium.js:1: // Prevent polyfilled Shadow DOM in
Dartium
On 2014/03/06 18:18:08, Siggi Cherem (dart-lang) wrote:
> I wonder if this file should be here or in pkg/web_components/
> 
> I don't have a good ideas yet, but I wonder if we should name them similar to
> each other as well. For example, instead of
>  shadowdom_dartium.js & dart_support.js
> 
> we could do:
>   - dartium_support.js & dart2js_support.js
>   - dart_support_before.js & dart_support_after.js
>   - dart_support/before.js & dart_support/after.js
>   - dart_support/pre_polyfills.js & dart_support/post_polyfills.js

Hmmm. That's a good question. I'm not sure... it's tricky. The web_components
package is so far only about dart2js support for features that are natively
available in Dartium dart:html. This file is only to make Dartium able to
interoperate with JS code that uses Shadow DOM. Even then, it might not work
generally. But we'll test it for Polymer.js at least and try our best to keep it
working. I'm not sure if over time, the amount of Polymer-specific glue code
will change. I suspect this file won't be needed in 1-2 Chrome versions. That's
why I was hoping to keep it under "src/js" and not encourage most people to use
it.

The reason I called it shadow_dartium.js, is to give it a more descriptive name.
You only need it in Dartium, so it's kind of the opposite of platform.js, which
is only for dart2js and polymer.js. I thought about calling it something with
"_pre" but that didn't seem very descriptive. Maybe I didn't go descriptive
enough. Would "dartium_disable_shadowdom_polyfill.js" be too long?

(Note: if we decide to replace our TemplateBinding impl with the one in
web_components, then things would get legitimately confusing. At that point
web_components starts to look like a more generally used package...)

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/lib/src/load...
File pkg/polymer/lib/src/loader.dart (right):

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/lib/src/load...
pkg/polymer/lib/src/loader.dart:286: // TODO(jmesserly): what's going on here?
Are we getting a strange mix of
On 2014/03/06 18:18:08, Siggi Cherem (dart-lang) wrote:
> not sure I understand the TODO, what does this apply to? Or is it because of
the
> proto is Node check further down?

Well, at the time I didn't understand the problem either :D

It turns out we had two custom element registries -- one in the JS polyfill and
a native one in Dartium. I discovered this later on. But it is fixed now. So the
TODO can be removed and we don't need to use JS interop anymore to call
document.createElement.

Thanks for noticing the TODO! Now it is fixed :)

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/lib/src/load...
pkg/polymer/lib/src/loader.dart:316: proto['register'] = new
JsFunction.withThis(registerDart);
On 2014/03/06 18:18:08, Siggi Cherem (dart-lang) wrote:
> wow -- I knew you were going to do this, was just not expecting it to be done
> from the Dart side. Nice.

Yeah, it's kinda neat we can do it. It's a lot cleaner if written in JS. But
then we'd need yet-another-script in polymer.html, ugh :(

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/test/noscrip...
File pkg/polymer/test/noscript_test.dart (left):

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/test/noscrip...
pkg/polymer/test/noscript_test.dart:33: expect(querySelector('x-a') is
PolymerElement, isTrue);
On 2014/03/06 18:18:08, Siggi Cherem (dart-lang) wrote:
> we should make sure to announce this as part of the breaking changes (maybe
> include it in the CHANGELOG.md that noscript is handled by polymer.js)

Good call. Done.

[Jennifer Messerly, 2014-03-06 21:06:17]

also. I forgot to update pkg/polymer/pubspec.yaml. Doing so now.

[Siggi Cherem (dart-lang), 2014-03-06 21:26:44]

lgtm

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/CHANGELOG.md
File pkg/polymer/CHANGELOG.md (right):

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/CHANGELOG.md...
pkg/polymer/CHANGELOG.md:8: #### Pub version 0.10.0-dev
On 2014/03/06 21:05:08, John Messerly wrote:
> On 2014/03/06 18:18:08, Siggi Cherem (dart-lang) wrote:
> > since we already published this version, how about adding 0.10.0-dev.2 ?
> > 
> > I assume when we are about to release, we'll delete the -dev entries and
make
> > 0.10.0 contain all the bullets below.
> 
> hmmm, good question. We published -pre.0, I didn't fix the CHANGELOG tho. It
> doesn't seem like Pub displays prerelease ones:
> http://pub.dartlang.org/packages/polymer ... I'm guessing that's by design. In
> that case, maybe we can keep this as "-dev" and flip it to 0.10.0 after
release
> as a stable version?

interesting - sounds great.

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/lib/src/js/s...
File pkg/polymer/lib/src/js/shadow_dartium.js (right):

https://codereview.chromium.org/182193002/diff/60001/pkg/polymer/lib/src/js/s...
pkg/polymer/lib/src/js/shadow_dartium.js:1: // Prevent polyfilled Shadow DOM in
Dartium
On 2014/03/06 21:05:08, John Messerly wrote:
> On 2014/03/06 18:18:08, Siggi Cherem (dart-lang) wrote:
> > I wonder if this file should be here or in pkg/web_components/
> > 
> > I don't have a good ideas yet, but I wonder if we should name them similar
to
> > each other as well. For example, instead of
> >  shadowdom_dartium.js & dart_support.js
> > 
> > we could do:
> >   - dartium_support.js & dart2js_support.js
> >   - dart_support_before.js & dart_support_after.js
> >   - dart_support/before.js & dart_support/after.js
> >   - dart_support/pre_polyfills.js & dart_support/post_polyfills.js
> 
> Hmmm. That's a good question. I'm not sure... it's tricky. The web_components
> package is so far only about dart2js support for features that are natively
> available in Dartium dart:html. This file is only to make Dartium able to
> interoperate with JS code that uses Shadow DOM. Even then, it might not work
> generally. But we'll test it for Polymer.js at least and try our best to keep
it
> working. I'm not sure if over time, the amount of Polymer-specific glue code
> will change. I suspect this file won't be needed in 1-2 Chrome versions.
That's
> why I was hoping to keep it under "src/js" and not encourage most people to
use
> it.

Got it, make sense.

> 
> The reason I called it shadow_dartium.js, is to give it a more descriptive
name.
> You only need it in Dartium, so it's kind of the opposite of platform.js,
which
> is only for dart2js and polymer.js. I thought about calling it something with
> "_pre" but that didn't seem very descriptive. Maybe I didn't go descriptive
> enough. Would "dartium_disable_shadowdom_polyfill.js" be too long?
> 
> (Note: if we decide to replace our TemplateBinding impl with the one in
> web_components, then things would get legitimately confusing. At that point
> web_components starts to look like a more generally used package...)

I see - makes sense. dartium_disable_shadowdom_polyfill.js might be a bit too
long, but I'd be ok with it, especially since it's hidden in the html import, so
users are unlikely going to type it themselves.

https://codereview.chromium.org/182193002/diff/80001/pkg/polymer/pubspec.yaml
File pkg/polymer/pubspec.yaml (right):

https://codereview.chromium.org/182193002/diff/80001/pkg/polymer/pubspec.yaml...
pkg/polymer/pubspec.yaml:22: web_components: ">=0.3.1 <0.4.0"
just realized - we probably need to mark web_components as 0.3.1-dev and update
the constraint here.

[Jennifer Messerly, 2014-03-06 22:04:56]

Committed patchset #10 manually as r33398 (presubmit successful).