Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

how to get polymer and requirejs working together? #1463

Closed
davidmaxwaterman opened this issue Apr 29, 2015 · 1 comment
Closed

how to get polymer and requirejs working together? #1463

davidmaxwaterman opened this issue Apr 29, 2015 · 1 comment

Comments

@davidmaxwaterman
Copy link

I feel like I strayed from the topic somewhat in #1457, so I'm opening this.

I came across this problem while investigating the message output from this console.warning :

console.warn('Attributes on ' + this.localName + ' were data bound ' +

createdCallback: function() {
  if (this.templateInstance && this.templateInstance.model) {
    console.warn('Attributes on ' + this.localName + ' were data bound ' +
        'prior to Polymer upgrading the element. This may result in ' +
        'incorrect binding types.');
  }

which makes it seem like things are still happening in the wrong order. We have some unusual code that is tickling this problem - we're trying to use require.js to add a closure around the Polymer() call, like this :

<polymer-element name="my-element">
  <template>
  </template>
  <script>
    require(['lodash', 'js-signals'], function (_, signals) {
      Polymer('my-element', {
        ...
      });
    });
  </script>
</polymer-element>

This seems like an aesthetically 'clean' way to use require.js and Polymer together. However, having dug into this some, it seems like require is delaying the call to Polymer('my-element',{}) and so any element that imports this code can end up using the element before the call to Polymer('my-element',{}) is made; resulting in their registrations being queued in the wrong order...or something.

I've made some attempts to work around that problem. My most sane attempt is by using promises, like this :

<polymer-element name="parent-element">
  <script>
    var parentElementReady = new Promise( function (resolve, reject) {
      Promise.all([childElementReady, /* and other dependencies*/]).then( function () {
        require(['js-signals'], function (signals) {
          Polymer('parentElement', {
            ....
          }); // Polymer
          resolve();
        }); // require
      }); // Promise.all
   }); // Promise
  </script>
<polymer-element name="parent-element">

I made a stripped down version of our app to demonstrate the problem - it does work, mostly, but it is somewhat awkward, to say the least:

https://github.com/davidmaxwaterman/polyquire

Note that the problem with requirejs trying to load using the wrong paths now only occurs when I run the example in a background tab - I have been using the 'super auto refresh' chrome extension to automatically refresh the tab every two seconds, as a sort of automated test. It works just fine when the tab is in the foreground, but as soon as I switch to a different tab, the requirejs path errors occur once more.

I wonder if this issue still applies in 0.8 - 0.8 is master branch now, right, so I guess it still applies.

Any comments are welcome :)

@kevinpschaaf
Copy link
Member

Without an omniscient synchronizing mechanism (which 0.5 partly attempted), these are options available for the use case you point out:

  1. Require requireJS modules in Polymer lifecycle functions (as opposed to gating Polymer registration on requireJS modules resolving) so that elements upgrade normally, and use a handshake protocol (e.g. events) to notify users when API/features that depend on requireJS become available.
  2. Vend built (browserify/webpacked) JS instead of relying on the requireJS runtime loader to avoid user code needing to synchronize with the runtime loader
  3. Situate script that defines Polymer elements that depend on requireJS dependencies as requireJS modules; users would need to use requireJS and require those element definitions before usage

We may explore an optional deferred registration layer for 0.8+ to help in situations you mentioned, but we strongly suggest that when vending elements you try to reduce dependencies as much as possible so HTML Imports just work (aka options 1 or 2).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants