This repository has been archived by the owner on Jul 15, 2023. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Mouse events have key events rule #849
Mouse events have key events rule #849
Changes from 8 commits
212df0e
8ee3160
022893a
f4df075
6d337ac
e1208a7
5b7b442
a3d6833
7b65818
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Complains for now.
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.
@lizzzp1 could you change it to not complain if there's a
...
, actually? It would be annoying to have a...props
that includes the correct correspondingonBlue
/onFocus
and still have this complain.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 thought that required the type checker that was a follow up? I'm really confused now.
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.
The type checker is just required to know whether the
...props
contains the correspondingonBlur
/onFocus
. Without the type checker, we have know way of knowing whether a JSX element that contains...props
violates the rule or not. Until the type checker logic is added, that leaves us with two options:...props
_(pretend they aren't therE): the rule would give complaints in some places where it shouldn't...props
contains the right attributes: the rule wouldn't give complaints in some places where it shouldIn order to not irritate folks with false complaints, IMO we should err on the side of caution with the first option.
Does that seem reasonable?
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.
Ok, if props are ignored then it would complain like the above wouldn't it? Wouldn't the 2nd option be better so it doesn't complain if it encounters spread props?
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.
Oh agh sorry I meant to say the second option! You're absolutely correct 😅