Fail no-container on use of innerHTML
CodingItWrong opened this issue · 6 comments
What rule do you want to change?
no-container
Does this change cause the rule to produce more or fewer warnings?
More warnings
How will the change be implemented?
The rule will look for usages of container.innerHTML in addition to looking for usages of methods like container.querySelector()
Example code
const { container } = render(<Greeting />);
expect(container.innerHTML).toContain("Hello");
How does the current rule affect the code?
The current rule allows this code. It only errors if a method like container.querySelector is accessed.
How will the new rule affect the code?
The updated rule would fail on usages of container.innerHTML just as it does with the methods.
Anything else?
Descriptions of the rule would need to be updated from saying "disallow the user of container methods" to "container methods and properties" (or something)
If we found that anyone has use cases where using innerHTML is commonly needed but container methods are not, we could either make it configurable whether it's allowed, or make it a separate rule very similar to no-container
Do you want to submit a pull request to change the rule?
Yes
This feels like this'll be as easy to add as the previous rule I added, or easier if it's OK to add this functionality into the existing rule. Happy to do the PR for it 👍
Hi @CodingItWrong. This is a great suggestion! We would appreciate a PR for implementing this, so definitely go for it by adding the functionality into the existing rule.
Sounds good, @obsoke and I plan to pair on it again over the next few weeks. Thanks for your input!
@Belco90 We were curious how restrictive we want to be when accessing properties on container. The issue proposes disallowing accessing innerHTML. Do we want to focus on solely this property for now? What about other properties such as firstChild, outerHTML, localName, etc.?
The rule currently disallows calling any methods on container so there is precedent for disallowing properties broadly as well. However, there might be valid use cases for some properties such as firstChild.