-
Notifications
You must be signed in to change notification settings - Fork 59
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
metal-web-component #261
metal-web-component #261
Conversation
d7cf48a
to
127f2d4
Compare
Hey @jbalsas I addressed the issue that was causing metal to be incompatible with the webcomponents polyfill, and now the tests are passing on all browsers that the polyfill supports. However the tests are still failing on IE9/10. I tried conditionally loading the polyfill, but the issue persists. Any thoughts on how we can get around this? It will also now work with JSX components, I've added tests to cover that use case. |
Hey @Robert-Frampton! Nice seeing this almost there!! What about having two different |
9fad590
to
61f7d23
Compare
@jbalsas the tests are passing now. Originally we were extending It turns out that the babel plugin was causing issues (the cause of the browserify error we were seeing). I removed the plugin, and just wrote the extension of |
Awesome, @Robert-Frampton, great job!! As part of closing this up... could we prepare a new tutorial in metaljs.com showing how to use this? We could maybe create a new branch where we push tutorials until we're ready to release a version with the updates. What do you think? |
Hey @jbalsas, Sounds good. Were you thinking of these kinds of tutorials? Or something more generic? |
I put together a quick guide on this branch. We could do something simple like this at first and provide a link to it in the metal-custom-element readme file, then later we can refactor some of these sections into actual tutorials like they have on wedeploy. On another note, the naming is currently inconsistent in this package. The package name is
|
Hey @Robert-Frampton, makes sense! So, from "Web Components", we use the I think I'd still rather go with the general The guide looks great, I think that is as much as we need right now 👍 |
Hey @jbalsas, I agree. I think I'll make the changes now 👍 |
Hey @jbalsas, updated the package name and sent the PR for the guide on metaljs.com. |
…be opted in on render
…empty object instead of null
bcfd972
to
c559dde
Compare
…e component has rendered in connectedCallback. Make sure we don't reference this.component before it's defined.
Hey @jbalsas, I think this is ready to merge whenever. Let me know if you see anything you think we should change. |
packages/metal-dom/src/domNamed.js
Outdated
@@ -168,7 +168,7 @@ export function append(parent, child) { | |||
if (isString(child)) { | |||
child = buildFragment(child); | |||
} | |||
if (child instanceof NodeList) { | |||
if (isArrayLike(child)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on this change in implementation we have now a different behaviour:
const child = ['a', 'b', 'c'];
dom.append(parent, child); // NOOP before -> 'abc' child after
Do we want to support this case? If so, we should probably add a test so it is clear. We might also simply do some duck-type-checking for NodeList
... from the ones I've seen maybe one of these could be good enough:
const el = ??;
const isNodeList = (typeof el.length != 'undefined' && typeof el.item != 'undefined');
const isNodeList = (typeof el.length == 'number' && typeof el.item == 'function' && typeof el.nextNode == 'function' && typeof el.reset == 'function');
"name": "metal-web-component", | ||
"version": "1.0.0", | ||
"description": "Web component (CustomElement) registration for Metal.js components.", | ||
"license": "BSD-3-Clause", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We have a bit of a mix between BSD
, BSD-3-Clause
and MIT
in this repo... might be good to have legal take a look :)
script.src = '/base/packages/metal-web-component/node_modules/@webcomponents/webcomponentsjs/webcomponents-lite.js'; | ||
script.type = 'text/javascript'; | ||
|
||
document.body.appendChild(script); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we do something similar for the babel-polyfill
, to make sure we don't load it when not necessary? I know it will probably noop in those cases, but it might have unintended side effects?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried conditionally loading this one as well, but it's harder to check if it's necessary than the webcomponents polyfill.
If you think it's necessary we can just explicitly check the user agent for every browser that needs it, but it won't be pretty.
packages/metal/src/coreNamed.js
Outdated
* @param {?} val Variable to test. | ||
* @return {boolean} Whether variable is an array/iterable. | ||
*/ | ||
export function isArrayLike(val) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comment above... might be better to just check for isNodeListLike
?
let el; | ||
|
||
before(function() { | ||
if (UA.matchUserAgent('MSIE') || isSafariVersion('8.0')) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume we don't have something in UA
to match version and user agent? :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Correct, it would be nice to have something in UA
that simply returns the major version number of the browser, regardless of what browser it is. We have a method in Portal that does something like that.
}); | ||
}); | ||
|
||
describe('Define JSX component', function() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why does this suite have different set of test cases than the Soy
one? If they are the same, then maybe we should simply put them outside the soy
one, or duplicate them in the jsx as well? Is there a chance one might work and not the other?
Object.setPrototypeOf(CustomElement, HTMLElement); | ||
|
||
Object.assign(CustomElement.prototype, { | ||
attributeChangedCallback: function(attrName, oldVal, newVal) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we document what goes on in each callback, just for reference?
226770e
to
116f523
Compare
116f523
to
b71e390
Compare
Hey @Robert-Frampton, LGTM! I'm going to go ahead and merge to |
No description provided.