-
Notifications
You must be signed in to change notification settings - Fork 12
Description
Type of Change
Enhancement / Bug
Summary
As observed in #114 coming over from ProjectEvergreen/greenwood#1079, the current design of WCC in particular around determining metadata for entry points, conveniently wrapping renderToString calls in a wrapping HTML element starts to fall apart when multiple customElement.define statements are in a single file.
So given this input
class Navigation extends HTMLElement {
connectedCallback() {
this.innerHTML = `
<nav>
<ul>
<li><a href="/">Home</a></li>
<li><a href="/about">About</a></li>
<li><a href="/artists">Artists</a></li>
<ul>
</nav>
`;
}
}
customElements.define('wcc-navigation', Navigation);
class Header extends HTMLElement {
connectedCallback() {
this.innerHTML = `
<header class="header">>
<h4>My Personal Blog</h4>
</header>
`;
}
}
export default Header;This is the current metadata output
{
html: '\n' +
' <wcc-navigation>\n' +
' \n' +
' <header class="header">>\n' +
' <h4>My Personal Blog</h4>\n' +
' </header>\n' +
' \n' +
' </wcc-navigation>\n' +
' ',
metadata: [
'wcc-navigation': {
instanceName: 'Navigation',
moduleURL: [URL],
source: 'class Navigation extends HTMLElement {\n' +
' connectedCallback() {\n' +
' this.innerHTML = `\n' +
' <nav>\n' +
' <ul>\n' +
' <li><a href="/">Home</a></li>\n' +
' <li><a href="/about">About</a></li>\n' +
' <li><a href="/artists">Artists</a></li>\n' +
' <ul>\n' +
' </nav>\n' +
' `;\n' +
' }\n' +
'}\n' +
"customElements.define('wcc-navigation', Navigation);\n" +
'class Header extends HTMLElement {\n' +
' connectedCallback() {\n' +
' this.innerHTML = `\n' +
' <header class="header">>\n' +
' <h4>My Personal Blog</h4>\n' +
' </header>\n' +
' `;\n' +
' }\n' +
'}\n' +
'export default Header;',
url: [URL],
isEntry: true
}
]
}
Details
As we can see <wcc-navigation> is considered the entry point, though technically that should belong to original moduleURL passed in, right?
Also, technically isn't the default export always going to be the entry point? This seems to substantiate #23 I suppose?
So it seems like the default export should be the entry point. And from there, if the class definition aligns with a customElements.define call, then that should decided if it is safe to wrap, or at least what the right tag to use is if wrapping is still desired.
Another call out though is that if there is only export default XXXX but no customElements.define how do we tracking this in metadata? Currently we use the tag name as a key, so will need to solve for that too.
Not sure if this is the same thing, or supplemental to #23 so should review them both as part of doing either these tasks.
This an acknowledged defect, but also requires a bit of rearchitecting I think so flagging as both since I don't the final solution here could be reasonably published as a "patch" fix in the spirit of the definition.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status