-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
[New] forbid-component-props
: add allowedForPatterns
and disallowedForPatterns
options
#3805
Conversation
…orPatterns` options
@ljharb what do you think? |
Thanks a lot for the feedback, I will apply the changes. |
This comment was marked as resolved.
This comment was marked as resolved.
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.
Should there also be examples of using propNamePatterns
with one of these new options?
message: { type: 'string' }, | ||
}, | ||
required: ['disallowedFor'], | ||
anyOf: [ |
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.
should this be:
anyOf: [ | |
oneOf: [ |
?
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.
Not sure, because with oneOf
you can't use disallowedFor
and disallowedForPatterns
simultaneously, while it is still a case. Here is one of the test cases for example: https://github.com/jsx-eslint/eslint-plugin-react/pull/3805/files#diff-0095adf2f1f3e139bb1a1666d7611671ad90ae66f67de0f5cdc7cb8884351968R825-R847
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.
with oneOf, only one is required but that shouldn't preclude using both, no?
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.
@ljharb so, based on the documentation, only one can be successful at a time https://json-schema.org/draft/2020-12/json-schema-core#section-10.2.1.3-2
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.
sure. but "only one is required" is the intended semantics, right?
i suppose they're identical semantics, but i read "anyOf" with more optionality than "oneOf", personally ¯\_(ツ)_/¯
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.
Yeah, semantically about "at least one required" they are identical probably, but "use several of them simultaneously" is not.
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.
right - and "any of" implies multiple matches are expected, "one of" implies only one match is expected
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.
So, to summarize:
anyOf
gives the ability to use several fields likedisallowedFor
anddisallowedForPatterns
at the same time;oneOf
forbids the use of several fields at the same time, as the usage of two fields is not valid in this case;
So, here we are, just discussing the difference, or are we considering the replacement with oneOf
? A bit hard to understand 😄
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.
lol i'm saying that i think that the actual behavior will be identical with anyOf or oneOf here, but that oneOf
seems more appropriate to me.
I won't hold up the PR further on this topic, though.
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 got it, so, actually, no.
With oneOf
, if you pass at the same time disallowedFor
and disallowedForPatterns
- it will be a validation error.
With anyOf
- it won't.
Also, I've added one for a more complex setup: https://github.com/jsx-eslint/eslint-plugin-react/pull/3805/files#diff-1cf5e390e9444274ee8064c64a72965facfa2171c5453a130f0329e57fe991adR106-R113 (Relates to this comment #3805 (comment)) |
For the future, correct me if I'm wrong, but here, |
Yes, feel free to do whatever you like, but I'll rebase and clean it up as part of landing it. |
##### [v7.37.0](https://github.com/jsx-eslint/eslint-plugin-react/blob/HEAD/CHANGELOG.md#7370---20240926) ##### Added - add type generation ([#3830][] [@voxpelli](https://github.com/voxpelli)) - \[`no-unescaped-entities`]: add suggestions ([#3831][] [@StyleShit](https://github.com/StyleShit)) - \[`forbid-component-props`]: add `allowedForPatterns`/`disallowedForPatterns` options ([#3805][] [@Efimenko](https://github.com/Efimenko)) - \[`no-unstable-nested-components`]: add `propNamePattern` to support custom render prop naming conventions ([#3826][] [@danreeves](https://github.com/danreeves)) ##### Changed - \[readme] flat config example for react 17+ ([#3824][] [@GabenGar](https://github.com/GabenGar)) [7.36.2]: jsx-eslint/eslint-plugin-react@v7.36.1...v7.36.2 [#3831]: jsx-eslint/eslint-plugin-react#3831 [#3830]: jsx-eslint/eslint-plugin-react#3830 [#3826]: jsx-eslint/eslint-plugin-react#3826 [#3824]: jsx-eslint/eslint-plugin-react#3824 [#3805]: jsx-eslint/eslint-plugin-react#3805
Initially, issue was described here, but it was closed by another PR (although this PR implements different case).
So, this PR just reimplements
Regex
implementation withglobs
as was suggested in one of the comments.