Automatic node finding (this.$) can blow up with existing code

[ebidel]

Not a bug in Polymer per se, but I spent a lot of time scratching my head tonight. Maybe we can prevent future grief.

The HTML5 slide deck I'm using defines HTMLElement.prototype.$:

window.$ = function(selector, opt_scope) {
  var scope = opt_scope || document;
  return scope.querySelector(selector);
};

HTMLElement.prototype.$ = function(selector) {
  return $(selector, this);
};

Requirejs loads this code before the polymer import. This means base.js picks up the $ function instead of creating it's empty hash:

marshalNodeReferences: function(root) {
  // establish $ instance variable
  var $ = this.$ = this.$ || {};

and thus, this.$ went bonkers when elements used it.

[addyosmani]

Is a short term 'fix' to document that you should either avoid overriding $ or ensure that Polymer is loaded in the correct order to avoid things going cray?

[sjmiles]

Can you be more specific about the nature of the bonkers. Specifically, it's not obvious how having $ be a Function would cause any particular failure. IOW, a Function is also an Object.

HTMLElement.prototype.$ = ...

This is an outright name collision, so long-term I don't know how we avoid this problem. Any library that wants to put something on HTMLElement.prototype will potentially collide with some Custom Element.

[sjmiles]

Oh, Steve points out there was only one instance of $ for all elements. Yes, that would cause bonkers. =P

[ebidel]

That's right.

var $ = this.$ = this.$ || {}; -> var $ = this.$ = {}; would do the trick, but that might mess things up for extended elements.

[sjmiles]

It's easy to ensure our $ wins, the problem is when whoever installed his own $ tries to use it.

[sjmiles]

Setting HTMLElement.prototype.$ is an anti-pattern. There is no way to solve this completely under those conditions.