Skip to content

how to get polymer and requirejs working together? #1463

Description

@davidmaxwaterman

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 :)

Activity

  1. kevinpschaaf commented on May 22, 2015

    @kevinpschaaf
    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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions