IE11 support for this project confirmed to work via fork
wbern opened this issue · 8 comments
Hello!
This issue is with regards to the old issue #31. At that time, it was not completely clear what the downsides were of running this project in IE 11.
My organisation have a fork for this project, and we've ironed out the issues we identified in IE 11 (namely some issues with ShadyDOM's implementation with mutation observer webcomponents/polyfills#81). The fork can be found below, and is published under npm package @telia/vue-web-component-wrapper-ie11
https://github.com/TeliaSweden/vue-web-component-wrapper-ie11
Npm: https://www.npmjs.com/package/@telia/vue-web-component-wrapper-ie11
I'd like to ask the maintainers of this project to reconsider supporting IE 11 again, for the good of the masses. Coincidentally, I believe transpiling your project to support ES5 is of the norm in the frontend community, which is actually really just what it takes for this project to become IE 11 compatible. That, and the fixes we applied from my org, should take this project to a more than capable level on IE 11.
Worst case, perhaps, offer a disclaimer mentioning lack of support for older browsers like IE 11?
FWIW, Updated the README.MD in the fork to tell more clearly what the fork adds. https://github.com/TeliaSweden/vue-web-component-wrapper-ie11
Why don't create PR?
Why don't create PR?
I'd love to! I just want to make sure to have this discussion first, because the last PR someone spent effort making was not handled and finally rejected after a lot of pings to maintainers. After we've discussed it I'd be happy to submit a PR.
@wbern I just gave this a try, and firstly: thanks for all your work you've done! I have a question regarding handling of styles: The original webcomponent-wrapper would attach the components styles in the shadow dom to the component. Your implementation does not do any of that — is there a reason for that? I feel like a good middle ground would be to include the styles globally once and additionally for modern browsers use the shadow dom. I might be wrong though :)
@wbern I just gave this a try, and firstly: thanks for all your work you've done!
You're welcome!
The original webcomponent-wrapper would attach the components styles in the shadow dom to the component. Your implementation does not do any of that — is there a reason for that?
Actually, the injection of styles into a Shadow DOM is something vue-loader does, through it's shadowMode option!
Since this option is defined during the build-step, you can either
- Compile Web Components (
shadowMode: true), and don't expose Vue Components at all. - Compile Web Components (
shadowMode: true) in one bundle, and compile Vue Components (shadowMode: false) in a separate bundle
In my org, we need the flexibility of exporting Vue Components as well as Web Components, which means we needed two bundles. Adding a second bundle just for this step felt a little overkill when just starting out, so we made the style injector to fit our use-case.
There is also the case where you as a developer have already maintained an application for some time, and you want most of the global styles to be applied to your Web Component for simplicity during, say, a transition period between an old framework and Web Components. When I search for this type of question online, most refer to doing injections this way.
I feel like a good middle ground would be to include the styles globally once and additionally for modern browsers use the shadow dom. I might be wrong though :)
IE 11 and Legacy Edge should be fine with either style injection or Vue's shadowMode, although I haven't extensively tested the last option.
Bottom line, you may need to judge your own situation, if you have a lot of legacy things that will need integration support to your Vue Web Components. There are a lot of options for the style injection, so you could theoretically just inject some styles that would be a hassle to import in other ways.
@wbern Thanks for your extensive and really helpful answer! While playing around with it further, I noticed another strange behaviour in IE11. Consider the following case:
<custom-component title="My custom component" data-select-custom-component>
<nested-component label="Label of nested component" data-select-nested-component></nested-component>
</custom-component>When doing something like this in Javascript:
elCustomComponent = document.querySelector('[data-select-custom-component]')
elNestedComponent = document.querySelector('[data-select-nested-component'])
elNestedComponent.setAttribute('label', 'Changed label')it does not change the label — actually the label attribute is changed when looking at it in the dev tools but it does not render the changed label.
If I additionally change some attribute on the other element, everything it is working for the nested component aswell:
elCustomComponent = document.querySelector('[data-select-custom-component]')
elNestedComponent = document.querySelector('[data-select-nested-component'])
elNestedComponent.setAttribute('label', 'Changed label')
elCustomComponent.setAttribute('title', 'Changed title')I checked this behaviour against web components created with https://open-wc.org/ and there it is working like expected. So it might not be related to the polyfills.
I might in a next step check with this library: https://github.com/karol-f/vue-custom-element
By the way, maybe it'd make sense to enable issues on your repository?
@wbern Just a quick follow-up regarding
I might in a next step check with this library: https://github.com/karol-f/vue-custom-element
It's working aswell. It's either something with your fork or I'm doing something wrong 😬
@thomasaull yes we've had some other issues with attribute assignment, so I guess we did not cover them all yet.. :-)
My org will have to look into this (right now we're working with exporting React components as Web Components), but if you beat us to it that's fine.
Appreciate you reporting the issue!