bug/issue 170 handle support for element properties #184
Conversation
…lement which allows for element properties without having to change API - Removed excessive commenting in dom-shim - Added a test case for setting element properties with a custom renderer - Added a test case for setAttribute
There was a problem hiding this comment.
Couple minor comments, but also wondering if there's anything we would want to document as part of this, or is this just kind of BAU (business as usual)?
- https://merry-caramel-524e61.netlify.app/ (key features)
- https://merry-caramel-524e61.netlify.app/docs/
Either way, let me do the usual Greenwood regression test run on this and will report back in a few. 🫡
| @@ -161,11 +160,7 @@ async function initializeCustomElement(elementURL, tagName, node = {}, definitio | |||
| if (element) { | |||
| const elementInstance = new element(data); // eslint-disable-line new-cap | |||
|
|
|||
| elementInstance.childNodes = childNodes; | |||
|
|
||
| before(async function () { | ||
| const { html } = await renderToString(new URL('./src/index.js', import.meta.url)); | ||
| console.log(html); |
| @@ -14,7 +14,7 @@ function isShadowRoot(element) { | |||
|
|
|||
| function deepClone(obj, map = new WeakMap()) { | |||
| if (obj === null || typeof obj !== 'object') { | |||
| return obj; // Return primitives or functions as-is | |||
| return obj; | |||
There was a problem hiding this comment.
Just to confirm, are all the changes here just removing comments?
There was a problem hiding this comment.
Yes, this is correct!
thescientist13
changed the title
There was a problem hiding this comment.
Although GitHub actions don't seem to be running on ProjectEvergreen/greenwood#1340, at least locally this latest patch test is working and all Greenwood test cases are passing, and the website is looking good too!
I think just clean up that console log and we are good to go here.
I couldn't think of a reason to add documentation for this except for maybe pointing to the related test case. The only other thing I could think of, and it feels like it's out of the scope of general WCC documentation, is to point out that when writing a renderer that will be used by WCC, this is the (loose) pattern to go with: const parsedContent = parseFragment(content);
const template = document.createElement('template');
template.content.childNodes = parsedContent.childNodes;
container.appendChild(template.content.cloneNode(true));And innerHTML should be avoided unless you don't care about nodes retaining their properties. Maybe also mentioning that parse5 is used under the hood and is the recommended way to write a renderer that assigns properties. I just couldn't find a way to fit those ideas into the general documentation as they seem a bit abstract and separate from the main concepts expressed there. In the future, once I've finished my framework and documented how to integrate it with WCC, I think I might have a clearer vision here of things I'd recommend adding to the docs. |
Related Issue
Resolves #170
Summary of Changes
Loosely related