You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 :
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:
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 :)
The text was updated successfully, but these errors were encountered:
Without an omniscient synchronizing mechanism (which 0.5 partly attempted), these are options available for the use case you point out:
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.
Vend built (browserify/webpacked) JS instead of relying on the requireJS runtime loader to avoid user code needing to synchronize with the runtime loader
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).
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 :
polymer/src/instance/base.js
Line 119 in e4f64ff
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 :
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 :
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 :)
The text was updated successfully, but these errors were encountered: