Import polymer in a single place and remove d3 hacks

Import polymer in a single place and remove d3 hacks

All key bootstraps just import tracing/ui/base/polymer.html which then initializes Polymer to shadow mode before importing. As part of this, I removed our dependence on webcomponents (sometimes lite, sometimes not!) because we're Chrome only.

But, you will notice these ugly polymer preload and postload scripts. This is a temporary workaround for #2698, in which PyVulcanize causes us to reorder scripts relative to imports.

Another thing "fixed" in this CL is the early- and incorrect import of D3 added during the Polymer conversion. D3 didn't work because its "generic" module loader that is in d3-min.js gets confused by being inlined (I'm a little confused why). The "better hack" I replaced the early loading with is to trick the d3 module loader into thinking that there's an AMD module loader present, via a preload and postload script. In a world where #2698 was fixed, we could have these be inline in the d3.html bootstrap.


BUG=catapult:#2580

Committed: https://chromium.googlesource.com/external/github.com/catapult-project/catapult/+/9be0433d2f769c91b70c4851f1deb8f3f8682412

[nduca, 2016-08-20 02:01:54]

nduca@chromium.org changed reviewers:
+ aiolos@chromium.org, charliea@chromium.org, sullivan@chromium.org

[nduca, 2016-08-20 02:01:54]

I think this fixes our polymer importing issues. PTAL.

[nduca, 2016-08-20 02:02:01]

Description was changed from

==========
Import polymer in a single place and remove d3 hacks

BUG=catapult:#2580
==========

to

==========
Import polymer in a single place and remove d3 hacks

All key bootstraps just import tracing/ui/base/polymer.html which then
initializes Polymer to shadow mode before importing. As part of this, I removed
our dependence on webcomponents (sometimes lite, sometimes not!) because we're
Chrome only.

But, you will notice these ugly polymer preload and postload scripts. This is a
temporary workaround for #2698, in which PyVulcanize causes us to reorder
scripts relative to imports.

Another thing "fixed" in this CL is the early- and incorrect import of D3 added
during the Polymer conversion. D3 didn't work because its "generic" module
loader that is in d3-min.js gets confused by being inlined (I'm a little
confused why). The "better hack" I replaced the early loading with is to trick
the d3 module loader into thinking that there's an AMD module loader present,
via a preload and postload script. In a world where #2698 was fixed, we could
have these be inline in the d3.html bootstrap.


BUG=catapult:#2580
==========

[aiolos (Not reviewing), 2016-08-22 23:19:27]

lgtm with a question

https://codereview.chromium.org/2267503002/diff/1/tracing/tracing/ui/base/d3_...
File tracing/tracing/ui/base/d3_preload.js (right):

https://codereview.chromium.org/2267503002/diff/1/tracing/tracing/ui/base/d3_...
tracing/tracing/ui/base/d3_preload.js:7: window.define = function(x) {
Do we need to worry about window.define already being defined in js somewhere
else, and us breaking them when we set it to undefined after we load d3? I
didn't see window.define being used elsewhere in tracing, so I'm hoping not.

[eakuefner, 2016-08-23 22:41:38]

eakuefner@chromium.org changed reviewers:
+ eakuefner@chromium.org

[eakuefner, 2016-08-23 22:41:39]

lgtm -- i'd like to land this (even though nat is on vacation) because results2
is broken because of the kind of pyvulcanize reordering stuff that the CL
description talks about, and i can't fix it without breaking this CL or adding
similar plumbing.

https://codereview.chromium.org/2267503002/diff/1/tracing/tracing/ui/base/d3_...
File tracing/tracing/ui/base/d3_preload.js (right):

https://codereview.chromium.org/2267503002/diff/1/tracing/tracing/ui/base/d3_...
tracing/tracing/ui/base/d3_preload.js:7: window.define = function(x) {
On 2016/08/22 at 23:19:27, aiolos wrote:
> Do we need to worry about window.define already being defined in js somewhere
else, and us breaking them when we set it to undefined after we load d3? I
didn't see window.define being used elsewhere in tracing, so I'm hoping not.

I don't think so, because window.define is used by require.js. Although tracing
is available as a node module, people who are using it in that context are
unlikely to import d3, so I think this should be fine.

[eakuefner, 2016-08-23 22:42:00]

The CQ bit was checked by eakuefner@chromium.org

[commit-bot: I haz the power, 2016-08-23 22:42:11]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-23 23:54:53]

Description was changed from

==========
Import polymer in a single place and remove d3 hacks

All key bootstraps just import tracing/ui/base/polymer.html which then
initializes Polymer to shadow mode before importing. As part of this, I removed
our dependence on webcomponents (sometimes lite, sometimes not!) because we're
Chrome only.

But, you will notice these ugly polymer preload and postload scripts. This is a
temporary workaround for #2698, in which PyVulcanize causes us to reorder
scripts relative to imports.

Another thing "fixed" in this CL is the early- and incorrect import of D3 added
during the Polymer conversion. D3 didn't work because its "generic" module
loader that is in d3-min.js gets confused by being inlined (I'm a little
confused why). The "better hack" I replaced the early loading with is to trick
the d3 module loader into thinking that there's an AMD module loader present,
via a preload and postload script. In a world where #2698 was fixed, we could
have these be inline in the d3.html bootstrap.


BUG=catapult:#2580
==========

to

==========
Import polymer in a single place and remove d3 hacks

All key bootstraps just import tracing/ui/base/polymer.html which then
initializes Polymer to shadow mode before importing. As part of this, I removed
our dependence on webcomponents (sometimes lite, sometimes not!) because we're
Chrome only.

But, you will notice these ugly polymer preload and postload scripts. This is a
temporary workaround for #2698, in which PyVulcanize causes us to reorder
scripts relative to imports.

Another thing "fixed" in this CL is the early- and incorrect import of D3 added
during the Polymer conversion. D3 didn't work because its "generic" module
loader that is in d3-min.js gets confused by being inlined (I'm a little
confused why). The "better hack" I replaced the early loading with is to trick
the d3 module loader into thinking that there's an AMD module loader present,
via a preload and postload script. In a world where #2698 was fixed, we could
have these be inline in the d3.html bootstrap.


BUG=catapult:#2580

Committed:
https://chromium.googlesource.com/external/github.com/catapult-project/catapu...
==========

[commit-bot: I haz the power, 2016-08-23 23:54:54]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/external/github.com/catapult-project/catapu...