Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Extend processPropertyIdentity to handle Element #65

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

Merged
merged 1 commit into from
Jan 25, 2023

Conversation

seanpdoyle
Copy link
Contributor

Closes github/template-parts#62

Extends the processPropertyIdentity function from the processors module to pass-through Element instances, instead of coercing them through calls to String(). In order to accommodate that change, this commit also extends the TemplatePart interface to accept Element instances for its value: property.

The change to the createTreeWalker invocation within collectParts was highlighted by TypeScript, as the final boolean argument doesn't conform to the createTreeWalker signature. It was a necessary change to build the project and execute the test suite locally.

Closes [github#62][]

Extends the `processPropertyIdentity` function from the `processors`
module to pass-through `Element` instances, instead of coercing them
through calls to `String()`. In order to accommodate that change, this
commit also extends the `TemplatePart` interface to accept `Element`
instances for its `value:` property.

The change to the `createTreeWalker` invocation within `collectParts`
was highlighted by TypeScript, as the final `boolean` argument doesn't
conform to the [createTreeWalker][] signature. It was a necessary change
to build the project and execute the test suite locally.

[github#62]: github#62
[createTreeWalker]: https://developer.mozilla.org/en-US/docs/Web/API/Document/createTreeWalker
@seanpdoyle seanpdoyle requested a review from a team as a code owner December 12, 2022 04:27
@primer-css
Copy link

👋 Hello and thanks for pinging us! This issue or PR has been added to our inbox and a Design Infrastructure first responder will review it soon.

  • 🎨 If this is a PR that includes a visual change, please make sure to add screenshots in the description or deploy this code to a lab machine with instructions for how to test.
  • If this is a PR that includes changes to an interaction, please include a video recording in the description.
  • ⚠️ If this is urgent, please visit us in #primer on Slack and tag the first responders listed in the channel topic.

Copy link

@rezrah rezrah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks @seanpdoyle, nice improvement 👍

@seanpdoyle
Copy link
Contributor Author

thanks @seanpdoyle, nice improvement 👍

🎊!

Could you grant permission for this PR's CI to execute the test suite?

@rezrah
Copy link

rezrah commented Dec 13, 2022

Could you grant permission for this PR's CI to execute the test suite?

Done 👍

Copy link
Contributor

@keithamus keithamus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@seanpdoyle
Copy link
Contributor Author

@rezrah @keithamus what are the next steps involved in incorporating these changes into a release?

@keithamus keithamus merged commit 5c3e242 into github:main Jan 25, 2023
@seanpdoyle seanpdoyle deleted the node-template-part branch December 9, 2024 01:28
seanpdoyle added a commit to seanpdoyle/template-parts that referenced this pull request Dec 9, 2024
Related to [github#62][] (see [3.2. Template Parts and Custom Template Process Callback][])
Follow-up to [github#65][]

While the changes made in [github#65][] improved support for `Element` parts,
the expansion from `string` to `Element | string` was not broadened
enough. While all `Element` instances are DOM Nodes, not all DOM Nodes
are `Element` instances.

For example, this change enables support for [DocumentFragment][]
instances (generated from classes like [Range][] or properties like
[HTMLTemplateElement.content][]), where prior support resulted in
templating the `[object DocumentFragment]` text string instead of the
fragment's `Node` instances.

[github#62]: github#62
[3.2. Template Parts and Custom Template Process Callback]: https://github.com/WICG/webcomponents/blob/159b1600bab02fe9cd794825440a98537d53b389/proposals/Template-Instantiation.md#32-template-parts-and-custom-template-process-callback
[github#65]: github#65
[DocumentFragment]: https://developer.mozilla.org/en-US/docs/Web/API/DocumentFragment
[HTMLTemplateElement.content]: https://developer.mozilla.org/en-US/docs/Web/API/HTMLTemplateElement/content
@seanpdoyle
Copy link
Contributor Author

I've opened #73 as a follow-up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support for templating DOM Nodes
4 participants