-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
feat(isRgbColor): add allowSpaces
option to allow/disallow spaces between color values
#2029
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #2029 +/- ##
==========================================
Coverage 100.00% 100.00%
==========================================
Files 108 104 -4
Lines 2482 2215 -267
Branches 627 481 -146
==========================================
- Hits 2482 2215 -267 ☔ View full report in Codecov by Sentry. |
test/validators.js
Outdated
'rgba(255, 255, 255, 0.5)', | ||
], |
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 think it's worthwhile to add a test case like this for clarity's sake:
'rgba(255, 255, 255, 0.5)', | |
], | |
'rgba(255, 255, 255, 0.5)', | |
'r g b( 0, 251, 222 )', | |
], |
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.
changed so that it does not ignore spaces between rgb at start, and added the test cases
@@ -4,16 +4,19 @@ const rgbColor = /^rgb\((([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5]),){2} | |||
const rgbaColor = /^rgba\((([0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5]),){3}(0?\.\d|1(\.0)?|0(\.0)?)\)$/; | |||
const rgbColorPercent = /^rgb\((([0-9]%|[1-9][0-9]%|100%),){2}([0-9]%|[1-9][0-9]%|100%)\)/; | |||
const rgbaColorPercent = /^rgba\((([0-9]%|[1-9][0-9]%|100%),){3}(0?\.\d|1(\.0)?|0(\.0)?)\)/; | |||
const startsWithRgb = /^rgba?/; |
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.
Why did you add this? Isn't it already checked in the first section of the other regexes?
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.
Ah, I see. It's because the newly added test is invalid. Why is that?
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 that we can check that it does not haves spaces between r g b and a only for the rest of the string
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 figured 'r g b( 0, 251, 222 )'
failing validation but 'rgb( 0, 251, 222 )'
passing is more inline with what an rgb color string is
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.
LGTM!
Could it be useful to have a Strictness has come up a few times before, and there is an ongoing process with the ISO8601 validator which stems from people expecting different levels of strictness (the ISO8601 standard includes a lot of different formats, but people often want only one specific timestamp format). |
it's possible to add a boolean parameter and switch between old and new behaviour. My intent was just to resolve the issue faced in #2028 |
I think that is the safest approach. If we want to avoid breaking changes, the function should take an options object that defaults to Personally I would lean towards having it default to false and just do a major version bump. It just makes more sense that it is lax by default and you have to actively make it stricter. In that case you should write a clear descriptor of what the breaking change entails. I suggest changing the title of the PR to |
I agree that we want the default to be false, but I think we can go forward with this PR with |
Perhaps it is more elegant to make a PR for that right away and state in the title that it should be merged for the next major version. It's easy to forget TODOs deep in the source code. |
Making a second PR right after this is merged to keep for the next major release would indeed be better. Good point! |
So is this PR good to go? |
src/lib/isRgbColor.js
Outdated
|
||
export default function isRgbColor(str, includePercentValues = true) { | ||
export default function isRgbColor(str, includePercentValues = true, strict = true) { |
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 would use an options object here instead of individual arguments.
I think something should be done so that the function will be backwards compatible. There are examples of this somewhere in this repo, but I don't remember exactly where I've seen it
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.
We should indeed make includePercentValues
backwards compatible if we move to an options object (which has my preference as well, see #1874 ). An example for this is;
validator.js/src/lib/isLength.js
Lines 8 to 14 in 86a07ba
if (typeof (options) === 'object') { | |
min = options.min || 0; | |
max = options.max; | |
} else { // backwards compatibility: isLength(str, min [, max]) | |
min = arguments[1] || 0; | |
max = arguments[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.
is something like 301e707 what you had in mind? 🙂
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.
We don't want to present both ways of providing options in the readme. Just describe the object parameter. The backwards compatibility is just there to avoid breaking changes for existing codebases. I don't think we should actively promote the old (inferior) way.
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.
@braaar updated readme
src/lib/isRgbColor.js
Outdated
options.includePercentValues : true; | ||
} else { | ||
// backward compaitable behaviour | ||
// Defaults |
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.
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 agree, we should have the object as the default behaviour. That makes the most sense to me.
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.
@a-h-i I still think it's worthwhile to flip the logic here and put the object in the else
clause
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.
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 think this is a clearer explanation
Co-authored-by: Brage Sekse Aarset <[email protected]>
Co-authored-by: Brage Sekse Aarset <[email protected]>
Co-authored-by: Brage Sekse Aarset <[email protected]>
Co-authored-by: Brage Sekse Aarset <[email protected]>
Co-authored-by: Brage Sekse Aarset <[email protected]>
This reverts commit 4c31a86.
This reverts commit 3f05aa5.
This reverts commit 09d9e95.
Co-authored-by: Brage Sekse Aarset <[email protected]>
@profnandaa rebased and resolved merge conflicts |
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.
LGTM, thanks for your contrib! 🎉
@WikiRik hey, sorry for the ping, I was wondering does it require another review? A bit unclear on the process from here |
@profnandaa will merge this one soon and then it should end up in the next release |
@rubiin -- can take a look at this again? looks like it was good to go? |
isRgbColor now behaves in a similar manner to HSL, and ignores spaces. fixes #2028
Stripped spaces in isRgbColor function
Checklist