skatejs / web-components Goto Github PK

@treshugart I am facing the issue described here using skatejs/web-components webcomponents/webcomponentsjs#777

I think this same issue was discussed/fixed in cloudyDOM skatejs/cloudydom#6

Is this change already pushed to skatejs/web-components or how do we get this fix implemented?

• custom-elements (v1 polyfill)
• shadydom (v1 polyfill)
• shadycss (v1 styling polyfill)

The reason is because <template> is not implemented in IE11.

One can of course add template polyfill like here http://codepen.io/elmariofredo/pen/mRazLq but from my understanding it doesn't have much sense to have shadyCss but not template polyfill in skate-web-components package.

Please let me know what do you think.

This happens in unit tests:

    ERROR: 'TypeError: Attempting to configurable attribute of unconfigurable property.'

might be nice to do another publish to npm soon, since the published version is dependent on cloudydom@^1.0.1. for me this resolves to [email protected], which no longer contains the file cloudydom/src/env. It has been moved to cloudydom/src/shadydom, I believe.

https://github.com/skatejs/web-components/blob/v5.2.1/src/index.js#L39

Error is different than issue #10

jspm install npm:skatejs-web-components

Looking up npm:skatejs-web-components
     Updating registry cache...

warn Error on locate for github:webcomponents/custom-elements/archive/fc022e8.tar.gz
     GitHub packages must be of the form owner/repo.

warn Error on locate for github:webcomponents/shadycss/archive/19a46c9.tar.gz
     GitHub packages must be of the form owner/repo.

warn Error on locate for github:webcomponents/shadydom/archive/c162774.tar.gz
     GitHub packages must be of the form owner/repo.

warn Error locating github:webcomponents/custom-elements/archive/fc022e8.tar.gz.

err  Error locating github:webcomponents/custom-elements/archive/fc022e8.tar.gz.

warn Installation changes not saved.

When using the webcomponents.js custom element polyfill, window.HTMLElement is modified in such a way that breaks document.registerElement.

document.registerElement expects that if prototype is declared in the options, that its .constructor is configurable. When this requirement is not satisfied, an error like the following is emitted (this example comes from Chrome):

VM17049:156 Uncaught NotSupportedError: Failed to execute 'registerElement' on 'Document': Registration failed for type 'aui-item-link'. Prototype constructor property is not configurable.

The problem comes from https://github.com/webcomponents/webcomponentsjs/blob/b77ca743edecb6ec262d4ffe8443708dbe0be49b/src/CustomElements/v1/CustomElements.js#L471.

The difference is observable in unpolyfilled:

> Object.getOwnPropertyDescriptor(HTMLElement.prototype, 'constructor')
< Object {writable: true, enumerable: false, configurable: true}

vs polyfilled:

> Object.getOwnPropertyDescriptor(HTMLElement.prototype, 'constructor')
< Object {writable: false, enumerable: false, configurable: false}

Note the difference in configurable.

Compare
http://codepen.io/anon/pen/vXRRQr

with
http://codepen.io/anon/pen/bwvvOE

in firefox.

Unfortunately there are breaking changes. I tried upgrading to the latest sha, which was webcomponents/webcomponentsjs@393764a , but it failed.

My attempt to upgrade: #3
The failed upgrade in skatejs: skatejs/skatejs#748
My revert of it: #4

For now I'm going to have to fork webcomponents.js and skatejs-web-components so that I can get the fix that I wanted out of this. We should be able to upgrade eventually, but the failure is due to a breaking change (disconnected / attached were renamed to connected / disconnected in v1 webcomponents, so upgrading would mean skate 2.0, which I imagine would be unwise while we're waiting on the v1 spec).

@treshugart , I'm just going to depend on my forks for now, but if you have an opinion of what we should do, I'd love to know.

require('./native-shim');

https://bugs.webkit.org/show_bug.cgi?id=160331

Looking at https://github.com/skatejs/web-components/blob/master/src/index.js#L16 it seems like native-shim.js is always required, but (as I understand it) this file must remain ES6 or it won't work in Chrome. How do you deal with a situation where the user wants to transpile these polyfills to ES5 but selectively exclude native-shim.js?

tried to install via jspm and got following stdout:

 jspm install npm:skatejs-web-components
     Looking up npm:skatejs-web-components
     Updating registry cache...
     Looking up npm:document-register-element
     Looking up npm:skatejs-named-slots
     Downloading npm:[email protected]

warn Error on processPackageConfig
     Package.json dependency webcomponents.js set to github:webcomponents/webcomponentsjs#b77ca74, which is not a valid dependency format for npm.
     It's advisable to publish jspm-style packages to GitHub or another registry so conventions are clear.
     To skip npm compatibility install with jspm install npm:[email protected] "{jspmPackage: true}".

warn Error processing package config for npm:skatejs-named-slots.
ok   Installed npm:[email protected] (1.0.9)

err  Error processing package config for npm:skatejs-named-slots.

warn Installation changes not saved.

When fixing #36 I have encounter issue with build specifically sed command here https://github.com/skatejs/web-components/blob/master/webpack.config.js#L16 I'm not sure why it stopped working did resolve issue with following awkward fix

diff --git a/webpack.config.js b/webpack.config.js
index 083c495..07ada10 100644
--- a/webpack.config.js
+++ b/webpack.config.js
@@ -13,7 +13,7 @@ conf.plugins.push(new WebpackShellPlugin({
   onBuildStart: [
     // Escape all backtick characters so we can wrap it in a template literal.
     // eslint-disable-next-line
-    'sed -e "s/\\\`/\\\\\\\\\\`/g" ./node_modules/@webcomponents/custom-elements/src/native-shim.js > ./src/native-shim.js',
+    'sed -e \x27s/`/\\\\`/g\x27 ./node_modules/@webcomponents/custom-elements/src/native-shim.js > ./src/native-shim.js',

     // Wrap in a conditional eval so it doesn't get executed in non-supported environments.
     'echo "window.customElements && eval(\\`$(cat ./src/native-shim.js)\\`);" > ./src/native-shim.js'

@treshugart can you please verify that it's working on your machine it's really strange that it's working on CI. If it's working for you let's close this issue.

I was experiencing an issue with native-shim's implementation of setAttribute. It was automatically lower-casing attribute names, which interfered with my svg application (svg elements have some important camelCase attributes). Turns out this is fixed in newer versions of webcomponents/custom-elements (see here: webcomponents/custom-elements#14)

In my fork of this repository, I've upgraded to a newer version of custom-elements (v1.0.0-alpha.4). It fixed my problem and passed all the tests. Mind if I do a pull request? While I'm at it, I could also upgrade the cloudydom dependency to 1.0.2.

So as I've mentioned, I've tested out skate 5.x with stable release of https://github.com/webcomponents/webcomponentsjs 1.x

It works with skate but there are few critical issues:

• their loader is non bundling/async compliant
• user has to use /node_modules/@webomponents/webcomponentsjs/webcomponents-loader.js within html -> big issue is that their loader relies that there will be always node_modules folder even in dist bundle ( huh ) - relative paths ehm
• so you cannot use hashes for modules/chunks names for proper cache busting 👎
• also in non native browsers huge HTML Imports shim is always loaded which is really unnecessary for users of skate which are using modern tools and lang features ( es6 modules -> tree shaking )

But fortunately for us, varial heelflip is a no brainer , so I wrote custom loader which we can include within this project.

If you're ok with this @treshugart I'll add it here -> so no Breaking changes, we can publish it under subpath so user can use it like : import { lazyLoadPolyfills } from '@skate/web-components/loader

here is implementation:

https://github.com/Hotell/skate-starter/pull/1/files#diff-576f47b45fccf9ab3b7a0a75876182e1

usage:

yarn add @webcomponents/webcomponentsjs
yarn add @skatejs/web-components

// polyfills.js
import { lazyLoadPolyfills } from '@skatejs/web-components/loader'

lazyLoadPolyfills().then(bootstrap);

 // app bootstrap
 function bootstrap() {
   return System.import('./main');
 }

main.jsx

import { h, render } from 'preact'
import 'custom-wc-library'

const App = ({content}) => (
  <div>
     <wc-menu/>
     <wc-content>
        {content}
      </wc-content>
     <wc-footer/>
   </div>
)

render( <App/>, root )

Recently, I was hung up on a bug that was breaking basic event propagation in shadydoms. Callbacks were being called without binding the relevant context. I was using d3, which relies on this in callbacks. This bug was fixed in a very simple way here. But as you can see, that pull request has been sitting around for 2 months now (along with quite a few others).

Maybe consider using the cloudydom fork?

They use global and that only works in node, so we must pull in the main browse version explicitly instead of using Webpack's resolving.

<custom-style> element from ShadyCSS throws error with skate-web-components polyfill within browsers that implements shadow dom ( Chrome ... )

It throws during parsing

shadycss.min.js?6d2b:2481 Uncaught TypeError: Illegal invocation
    at HTMLElement.w._findStyle (shadycss.min.js?6d2b:2481)
    at Function.w.findStyles (shadycss.min.js?6d2b:2452)
    at Object.applyStyle (shadycss.min.js?6d2b:2128)
    at Object.updateStyles (shadycss.min.js?6d2b:2256)
    at shadycss.min.js?6d2b:2402

DEMO (with skate-web-components): http://codepen.io/Hotell/pen/VPbdGo?editors=1010

Although if polyfills are used separately, it works

DEMO (with webcomponents/@ polyfills) : http://codepen.io/Hotell/pen/ygbjRO?editors=1010

There's both index.js and index-with-deps.js. Both should be the same, but the index.js doesn't seem to include named-slots. Using indes-with-deps.js does, but they should be the same. We should probably only distribute an index.js instead of both since they should be the same and it'd remove ambiguity.

When installing the most recent version of skatejs-web-components with npm I'm getting the error:

Invalid Package: expected @webcomponents/template but found template.

Node version: 7.5.0
Npm version: 4.1.2

This allows us to use a versioned polyfill that even supports back to IE8. The in-built functionality that fills some Mutation Observer behaviour for unsupported browsers requires fixing, so including the Mutation Observer polyfill from webcomponents.js fixes it. When these issues are fixed in the v0 / v1 polyfill, we can remove the Mutation Observer fill.

When running skate-web-components through UglifyJS I am getting a run time exception in firefox and safari.

It seems like it is erroring out in the following dependency: https://github.com/Benvie/WeakMap

I'm liking what I see so far and am excited to start tinkering with skatejs! Seems the perfect way to move into web components for those who prefer a javascript api.

This may seem a strange request, but when I experiment with javascript I prefer to use the Khan Academy sand box for convenience. They do allow code from github, though it's less friendly for beginners who may find an interest, but other options include cdnjs and jsdeliver.

If there is a production ready version of this script/bundle, would you be so kind as to upload it to one of the later options? :-) Is it already there and I missed it?

Thanks in advance!

(Not sure this is the right venue for this; let me know if there's a better place to have this conversation)

For context: I'm interested in converting a set of AngularJS 1.x components to WCs, with Skate. We'd target IE11 + evergreens.

While doing some benchmarking I've found substantial performance hits when rendering web components, particularly in IE11. Slower than AngularJS 1.x, even I'm not sure if I'm doing something wrong in my benchmark, or if the polyfills themselves are slow, but I'd like another set of eyes on them.

Here's a few Webpackbins wherein I'm testing the load time to create 1k elements with various frameworks:

(Note: Webpackbin doesn't work in IE11, so I had to download the bins and npm start them locally)

So yeah, I don't think this is an issue with Skate (as vanilla custom elements experience the same issue), but perhaps with ShadyDOM in particular. But we likely won't be able to go forward with a WC rewrite of our library if it's going to result in a 5x slowdown in the browser used by the majority of our customers.

Any idea what might be going on? Maybe my tests aren't good benchmarks of real-world behavior?

The UA sniffing here:

does not work for Chrome for iOS's user agent. You end up with a JavaScript exception that prevents the file from loading. The erroneous user agent is:

Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_1 like Mac OS X) AppleWebKit/602.1.50 (KHTML, like Gecko) CriOS/57.0.2987.137 Mobile/14E304 Safari/602.1