-
Notifications
You must be signed in to change notification settings - Fork 25
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
Move polyfills to uPortal? #117
Move polyfills to uPortal? #117
Comments
Does React make the same recommendation? (Is it even possible to omit the polyfills in React-based Web Components?) The answers to these questions could make a big difference on how I would tend to see this issue. I'm inclined to agree with the link you posted. Although it is harder to make changes to polyfills in uPortal itself, there's a tremendous advantage in managing these concerns in one place (provided they can be effectively managed in one place). Our state-of-the art understanding of "how to do polyfills for Web Components" seems to change pretty regularly. (It's not a surprise... new technology.) Each time it changes, we'll be much better ff if we can update & release uPortal only, rather than an entire stable of Web Components. |
Currently it is not possible. |
/cc @jgribonvald @heyMP @btopro who also have experience with polyfilling for older browsers |
Our polymer 1 stuff just ships w babelhelpers and all components are compiled to es5. then we polyfill via webcomponents-lite which pulls in html import and resolves everything. What we're working on going forward is just the custom-element adapter stuff and babel and the webcomponents-loader that's the new easier method of integration. Can see this in a demo we're working on https://lrn-button-test.surge.sh (view source) |
this is why I don't roll babel into my elements. I apply that at the top of my deploys as per that demo file. I'm not sure if they are different |
Do you use |
I do, our build process transpiles to es5 w/ AMD module resolution. -lite is the old method of integration https://www.webcomponents.org/polyfills our build process spits out ES6 and ES5 capable and then the statement at the beginning looks at the browser and picks one to do the build to load. THis way we dont have to do the weird ES5 custom element thing |
We encountered the same issue and resolved it differently. We created a pollyfill project which we inject at the top of the page. This project uses modernizer to detect what is missing and then injects the missing pollyfills via webpack 4 dynamic imports. I was inspired by polyfill.io. The advantage of this library is it treats legacy and future pollyfills the same and only injects them when the browser does not support them. A lot less maintenance than with static imports which you are forced to police per project over time. |
@leighgordy : thanks to sharing your approach which seems less intrusive into projects ! |
@jgribonvald we did not want to rely on an external service, just in case something went wrong. You can host their service locally but it is not compatible with our infrastructure as is. So all I could do was reinvent the wheel! |
@leighgordy is the Edinburgh polyfill service something that could be open sourced? |
@ChristianMurphy Yes it can be, we are still awaiting approval to share IP but I have been told that should happen imminently. At which point ill be happy to share it. |
Sounds good, when that becomes available, we can take a look at potentially integrating that into uPortal core. |
https://cli.vuejs.org/guide/browser-compatibility.html#polyfills-when-building-as-library-or-web-components
suggests applying polyfills once in the wrapping application.
It may save some space for bundle size.
But... it increases the risk that we may miss a polyfill needed for older browsers.
Thoughts?
The text was updated successfully, but these errors were encountered: