Skip to content
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.

Sign up for GitHub

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

Jump to bottom

docs: Improve no-child-traversal-in-connectedcallback #130

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

docs: Improve no-child-traversal-in-connectedcallback #130

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
5aca527
docs: Improve no-child-traversal-in-connectedcallback
silverwind Mar 3, 2024
6577f2d
Update docs/rules/no-child-traversal-in-connectedcallback.md
silverwind Mar 6, 2024
5631c8d
Update docs/rules/no-child-traversal-in-connectedcallback.md
silverwind Mar 6, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion docs/rules/no-child-traversal-in-connectedcallback.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -31,7 +31,7 @@ class FooBarElement extends HTMLElement {
if (button) {
button.disabled = true
}
}).observe(this)
}).observe(this, {childList: true})
}
}
```
Expand All @@ -52,3 +52,5 @@ class FooBarElement extends HTMLElement {
## When Not To Use It

If you are comfortable with the edge cases of DOM traversal directly in the `connectedCallback` then you can disable this rule.

If your element is appended to the DOM via `.innerHTML` or similar methods, you should disable this rule because in such a case, the children are are available during `connectedCallback` and no mutations events will fire.
Copy link
Collaborator

Choose a reason for hiding this comment

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

I don't think we should add this because it's typically not possible to know what happens to your element, as it is up to the consumer how it is embedded.

For example if your element is appended to the DOM using append(), and you have disabled this rule, your code breaks. If your element is served from the source HTML, and browser decides to render, your element is connected but incomplete, you code breaks.

The point of this rule is to remind you that those cases exist, and to carefully think about how you want to approach them.

Copy link
Author

@silverwind silverwind Mar 6, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

I agree, disabling the rule as a whole is definitely too crude. I think a eslint-disable-line would be suitable for cases where you know exactly how your element is going to be inserted. Maybe it should just recommend that.

Copy link
Author

@silverwind silverwind Mar 6, 2024 •
edited
Loading

Choose a reason for hiding this comment

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

I think we could at least hint somewhere in the rule text that depending on the renderer, children may be available or not and I think any universally usable component that deals with its children has to check for both immediately and delayed availability of children.

I just fear that people who blindly follow this rule will create components that can not work correctly when inserted via .innerHTML, which I think is very common with frameworks like React or Vue.