-
-
Notifications
You must be signed in to change notification settings - Fork 22
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
connectedCallback super #36
Comments
@LarsDenBakker, @43081j and I had previously discussed covering this in the |
I intentionally didn't put it there, since you can't know which base class does or doesn't implement |
Would you mind opening an issue in eslint-plugin-wc? This would be a good rule. It can only really be detected by checking if the base class is This is the exact same reason why polymer-linter relied on the same JSDoc. A custom element's callbacks don't exist on an interface in the spec, they can exist or not on anything which can be registered as an element. Also, we can't do cross-file linting, which rules out inferring the base class through import traversal (because it goes against eslint conventions etc). |
Yup, checking for the presence of the The inverse of this rule could check that an element that is directly extending |
Do you mean that the consumer should be required to add the I'd prefer to either have this option in Another option is if you could set the base classes in the |
It belongs in the web components plugin rather than here, as the same detection algorithm would have to be used anyway if it was here. Closing this in place of 43081j/eslint-plugin-wc#32 |
In the lit context, don't you always want to call super.connectedCallback? no detection algorithm needed? |
I've been doing a lot of workshops where people learn to use lit-html. One of the most common mistakes is to forget calling super.connectedCallback() when using lit-element.
This would be a good linting rule to add.
The text was updated successfully, but these errors were encountered: