[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.
| message: { type: 'string' }, | ||
| }, | ||
| required: ['disallowedFor'], | ||
| anyOf: [ |
There was a problem hiding this comment.
should this be:
| anyOf: [ | |
| oneOf: [ |
?
There was a problem hiding this comment.
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.
with oneOf, only one is required but that shouldn't preclude using both, no?
There was a problem hiding this comment.
@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.
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.
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.
right - and "any of" implies multiple matches are expected, "one of" implies only one match is expected
There was a problem hiding this comment.
So, to summarize:
anyOfgives the ability to use several fields likedisallowedForanddisallowedForPatternsat the same time;oneOfforbids 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.
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.
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.
I've added one: https://github.com/jsx-eslint/eslint-plugin-react/pull/3805/files#diff-1cf5e390e9444274ee8064c64a72965facfa2171c5453a130f0329e57fe991adR79-R83 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
Regeximplementation withglobsas was suggested in one of the comments.