WebReflection/document-register-element

Double initialization on IE11

makeros opened this issue · 4 comments

Hi.
I've run into a little problem.
We are building components and each component is importing the polyfill by its own.
Everything is ok till we go to our tests.
We use karma runner and what we do is we load only specs into karma. Every spec is importing the component which is importing everything what he needs (with polyfill). So we end up with a small bundle with all dependecis for each componnet. So basically the browser is initializing polyfill many times.
In browsers like chrome and firefox it's ok since the polyfill is checking if everything is ready.
But in IE11 is't failing because of Promis which is polyfilled.
So for the first time in IE11 we have this polyfilled version of Promise but in the second initialization the polyfill is using Promise.race which is not available but the condition is saying that Promise is available. And that's why we receive then TypeError: Object doesn't support property or method 'race'.
I thinks that this is a bug but i'm also not sure if our approach with tests is correct.

It's of course failing whe we use the whenDefined method :)

it looks like usableCustomElements can be true only if you have already a global customElements that works or you force the polyfill.

The .race(...) is meant to be used only in one of those cases, indeed the little inner poly doesn't even care about it, because browsers without customElements won't ever race anything.

While there might be room for improvements in here, I wonder how your logic works 😄

  • you have a broken polyfill that doesn't provide standard .race method
  • you file a bug in a library that assumes if Promise is there is a proper one

Even patching the inner little Promise fallback, that race will fail because the fallback is not used if you provide your broken polyfiull upfront.

As summary:

  • where is the bug filed to the library that doesn't polyfill Promise correctly?
  • what do you expect me to do, exactly?

Regards

I think it is a dependencies management problem. It seems that including polyfills in every component might not be the best practice. I would keep them separate. If you use npm or similar in your project it is easy enough to manage dependencies and include whatever you need in your test suite or final product code.

Here is an example of package.json we use in our project.

"devDependencies": { "custom-event-polyfill": "^0.3.0", "document-register-element": "^1.7.0", "es6-object-assign": "^1.1.0", "promise-polyfill": "^6.0.2" },

We bundle all polyfills later in one polyfills.min.js. You can use uglifyjs for that.

Secondary it is better to avoid including the same code twice in your project. You'd just wasting resources this way.

The thing is that for a production/development bundle we include the polyfill only once (as it should be).
But in our test we are preprocessing the spec file which is including everything so we end up with a small bundle with spec, component and polyfill. And i think it should be ok when we include more than once this polyfill (on chrome, firefox is working normally since when customElement are in place or polyfilled then it's not doing anything else). But in IE11 it's failing. (The race method in Promise).
And i'm a little bi afraid that when for some reasons the system which is responsible for assembling the page will include two packages with different components and the polyfill will be included in each one.
I will maybe try to use the promise-polyfill...

Hi.
Adding promise-polyfill fixed the issue for me.
Because we are building componentsfor our other systems we cannot guarantee that some of our client system will not include two seperate bundles with components and each bundle will have document-register-element inside. So then without promise-polyfill at the first place we will have errors on IE11.
But still, it'a a edge case and has been resolved by providing promises :)