-
Notifications
You must be signed in to change notification settings - Fork 789
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
fix(dist-custom-elements): add ssr checks #3131
Conversation
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.
The reason I think these tests are failing is rooted in a declaration ordering error. If you npm ci && npm run build && pushd test/karma && npm run karma.prod
, we see the tests fail (but that much you knew 🙃)
After doing that, open up www/custom-elements-delegates-focus/main.js
(from the test/karma
dir) and you'll see:
let CustomElementsDelegatesFocus$1 = class extends HTMLElementSSR {
constructor() {
super();
this.__registerHost();
this.__attachShadow();
}
render() {
return (h(Host, null, h("input", null)));
}
static get delegatesFocus() { return true; }
static get style() { return sharedDelegatesFocusCss; }
};
var HTMLElementSSR = (typeof HTMLElement !== "undefined" ? HTMLElement : class {
});
If I reorder those two statements:
+ var HTMLElementSSR = (typeof HTMLElement !== "undefined" ? HTMLElement : class {
+ });
let CustomElementsDelegatesFocus$1 = class extends HTMLElementSSR {
constructor() {
super();
this.__registerHost();
this.__attachShadow();
}
render() {
return (h(Host, null, h("input", null)));
}
static get delegatesFocus() { return true; }
static get style() { return sharedDelegatesFocusCss; }
};
- var HTMLElementSSR = (typeof HTMLElement !== "undefined" ? HTMLElement : class {
- });
that test passes (npm run karma
from within test/karma
to avoid a rebuild), so it looks like that aspect of the PR at least is rooted in these types of ordering issues.
I haven't given this PR too much other focus, but I think that might get you going again 🏃
Update: This is a separate issue, not concerned with this PR. Created new GH issue here: #3134 Hi @rwaskiewicz, when I test this build in Ionic Framework, I am receiving this error in our Vue e2e tests: The same error is described here: https://stackoverflow.com/questions/43836886/failed-to-construct-customelement-error-when-javascript-file-is-placed-in-head I don't believe this error is being caused by any of the changes in this PR, but this PR fixes earlier points of failure in those same e2e tests ( The stackoverflow link above expands on the error, stating that it originates from accessing attributes or children in the custom element's constructor, which should not happen as per spec: https://html.spec.whatwg.org/multipage/custom-elements.html#custom-element-conformance I am still familiarizing myself with the Stencil source and so I need some assistance verifying, do we follow the spec regarding the above? I see that the generated custom element for |
Pull request checklist
Please check if your PR fulfills the following requirements:
npm run build
) was run locally and any changes were pushednpm test
) were run locally and passednpm run test.karma.prod
) were run locally and passednpm run prettier
) was run locally and passedPull request type
Please check the type of change your PR introduces:
What is the current behavior?
GitHub Issue Number: #3101
What is the new behavior?
defineCustomElement
function now checks ifcustomElements
is defined.HTMLElement
is defined before extending from it:Does this introduce a breaking change?
Testing
Other information
This fix is a prerequisite for ionic-team/ionic-framework#24163