-
Notifications
You must be signed in to change notification settings - Fork 205
Update shadow-dom documentation #124
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
Conversation
A live preview of this PR will be available at the URL(s) below. https://pr124-32ae5f8---lit-dev-bvxw3ycs6q-uw.a.run.app/ |
@justinfagnani had proposed that we use a different term than "templated DOM" for the ... DOM that we render from the template. He proposed "internal DOM" to focus more on the "what" (DOM that's internal to the component) rather than the "how" (DOM rendered from a template). We should probably talk this through face to face. |
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.
Proposed some text changes. Also, there's a question about terminology we should answer. ("rendered DOM"/"rendered template"/"internal DOM"/something else)
By default, Lit components use [shadow DOM](https://developers.google.com/web/fundamentals/web-components/shadowdom) to encapsulate their templated DOM. | ||
|
||
{% playground-ide "docs/templates/shadowroot/" %} |
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.
Does having a sample here buy us anything? Not sure... If so I'd lean towards the playground-example element since there's nothing really to see here except the component class...
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.
Removed
|
||
## Accessing nodes in the shadow DOM | ||
|
||
The `render()` method result is usually rendered into shadow DOM, so the nodes are not direct children of the component. Use `this.shadowRoot.querySelector()` or `this.shadowRoot.querySelectorAll()` to find nodes in the | ||
shadow DOM. | ||
The `render()` method result is usually rendered into shadow DOM, so the nodes are not direct children of the component. To find nodes in shadow DOM, you can use `this.shadowRoot.querySelector()` or `this.shadowRoot.querySelectorAll()`. Note, because LitElement renders into a customizable `renderRoot` property, it is typically better to use `this.renderRoot.querySelector()` to find nodes in element DOM. |
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.
If this is better, why don't we just show it first instead of this.shadowRoot
?
Maybe, "To find nodes relative to the render root, use this.renderRoot.querySelector()
or ..."
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.
Updated.
Co-authored-by: Arthur Evans <arthure@google.com>
Co-authored-by: Arthur Evans <arthure@google.com>
Co-authored-by: Arthur Evans <arthure@google.com>
Co-authored-by: Arthur Evans <arthure@google.com>
Co-authored-by: Arthur Evans <arthure@google.com>
Co-authored-by: Arthur Evans <arthure@google.com>
Co-authored-by: Arthur Evans <arthure@google.com>
Co-authored-by: Arthur Evans <arthure@google.com>
* change to `component DOM` * remove superfluous sample
Simplify finding nodes in shadow DOM section.
Note, I went with |
Because of the code change related to Under the circumstances, I'm not sure whether we want to drop that section entirely, or just add an innocuous example inline in that section. |
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 think we should address the comment about the nothing
section, but otherwise I think this PR is good to go.
I'd like to revisit "component DOM," but I'll do that in a separate PR so I can reconcile the various places we refer to it.
Will handle removing the cross-reference in a separate PR on conditionals. |
Fixes #56, #57, #58.
Note, significantly shortened section on slot fallback content in anticipation of lit/lit#1561.