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.

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

Add new dom-elements-no-danger-with-children rule (Fixes #710) #719

Conversation

petersendidit
Copy link
Contributor

@petersendidit petersendidit commented Jul 26, 2016

Prevents dangerouslySetInnerHTML and children from being used at the same time (Fixes #710)

invalid: [
{
code: [
'<div dangerouslySetInnerHTML={{ __html: "HTML" }}>',
Copy link
Member

Choose a reason for hiding this comment

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

Can we also add a test that sets the "children" prop explicitly, in both cases?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good idea. Added.

Copy link
Member

Choose a reason for hiding this comment

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

I see you've added it for React.createElement, but not for the jsx example.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Didn't even think about passing a children prop in JSX. Seems just wrong to even do such thing. Will update the rule.

Copy link
Member

Choose a reason for hiding this comment

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

It's very wrong but we should still cover it :-)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added

Copy link
Collaborator

Choose a reason for hiding this comment

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

Sounds like another good rule would be to prevent a children prop on DOM elements.

Copy link
Member

Choose a reason for hiding this comment

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

I'd say on any elements - children should be actual children (in React.createElement as well)

Copy link
Collaborator

Choose a reason for hiding this comment

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

Ah, right. Good point!

Copy link
Collaborator

Choose a reason for hiding this comment

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

@petersendidit petersendidit force-pushed the dom-elements-no-danger-with-children branch 2 times, most recently from 8ed6f7e to 8773a33 Compare July 26, 2016 18:50
@petersendidit
Copy link
Contributor Author

Anything else needed to get this merged?

@@ -0,0 +1,39 @@
# Prevent problem with children and props.dangerouslySetInnerHTML (dom-elements-no-danger-with-children)

This rule helps prevent problems caused by using children and the dangerouslySetInnerHTML prop at the same time
Copy link
Collaborator

Choose a reason for hiding this comment

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

This sentence needs ending punctuation.

Also, it might be worth mentioning that React will issue a warning for this case.

@petersendidit
Copy link
Contributor Author

New commit should take care of the comments. Let me know if there is anything else.

docs: {
description: 'Report when a DOM element is using both children and dangerouslySetInnerHTML',
category: '',
recommended: true
Copy link
Member

Choose a reason for hiding this comment

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

The rule is not in the recommended configuration (yet).

Copy link
Member

Choose a reason for hiding this comment

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

It should be, though, since it's already a React error.

@yannickcr
Copy link
Member

Thanks, just a few small things:

  • Can you rename the rule to no-danger-with-children
  • Pass the recommended to false in the metadata
  • Rebase your branch

And then I think we'll be good to go :)

Prevents dangerouslySetInnerHTML and children from being used at the same time
@petersendidit petersendidit force-pushed the dom-elements-no-danger-with-children branch from a239cf2 to 5fbee0c Compare August 13, 2016 18:07
@petersendidit
Copy link
Contributor Author

Renamed and removed it from the recommended rules.

I do think these type of rules that are catching errors that React will throw itself should be recommend ASAP.

@lencioni
Copy link
Collaborator

Agreed. I think we should write them all, put out minor releases, and then
add them all to recommended config in a major release ASAP. That way we can
maximize benefit and minimize pain.

On Sat, Aug 13, 2016, 11:09 AM David Petersen notifications@github.com
wrote:

Renamed and removed it from the recommended rules.

I do think these type of rules that are catching errors that React will
throw itself should be recommend ASAP.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#719 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAL7zovEh2NROCC1sglDA5j8o_GOzYDrks5qfgg_gaJpZM4JVbyE
.

@ljharb
Copy link
Member

ljharb commented Aug 13, 2016

Although, I kind of feel like it's not really a semver-major if React would be throwing the error at runtime anyways.

@lencioni
Copy link
Collaborator

lencioni commented Aug 13, 2016

I think it is a warning

@yannickcr
Copy link
Member

I do think these type of rules that are catching errors that React will throw itself should be recommend ASAP.

Yes, it will be added to the recommended config on next major release.

@yannickcr yannickcr merged commit 7d3dbfd into jsx-eslint:master Aug 14, 2016
@yannickcr
Copy link
Member

Merges, thanks!

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

Successfully merging this pull request may close these issues.

4 participants