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

feat(isRgbColor): add allowSpaces option to allow/disallow spaces between color values #2029

Open
wants to merge 21 commits into
base: master
Choose a base branch
from

Conversation

a-h-i
Copy link

@a-h-i a-h-i commented Aug 15, 2022

isRgbColor now behaves in a similar manner to HSL, and ignores spaces. fixes #2028

Stripped spaces in isRgbColor function

Checklist

  • PR contains only changes related; no stray files, etc.
  • README updated (where applicable)
  • Tests written (where applicable)

@codecov
Copy link

codecov bot commented Aug 15, 2022

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 100.00%. Comparing base (83d6ffd) to head (97c1f70).
Report is 2 commits behind head on master.

❗ Current head 97c1f70 differs from pull request most recent head bfca688. Consider uploading reports for the commit bfca688 to get more accurate results

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.
📢 Have feedback on the report? Share it here.

WikiRik
WikiRik previously approved these changes Aug 15, 2022
Comment on lines 4280 to 4281
'rgba(255, 255, 255, 0.5)',
],
Copy link
Contributor

@braaar braaar Aug 16, 2022

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:

Suggested change
'rgba(255, 255, 255, 0.5)',
],
'rgba(255, 255, 255, 0.5)',
'r g b( 0, 251, 222 )',
],

Copy link
Author

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

@a-h-i a-h-i requested review from braaar and WikiRik and removed request for braaar and WikiRik August 16, 2022 12:24
@@ -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?/;
Copy link
Member

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?

Copy link
Member

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?

Copy link
Author

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

Copy link
Author

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

braaar
braaar previously approved these changes Aug 17, 2022
Copy link
Contributor

@braaar braaar left a comment

Choose a reason for hiding this comment

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

LGTM!

test/validators.js Outdated Show resolved Hide resolved
@braaar
Copy link
Contributor

braaar commented Aug 17, 2022

Could it be useful to have a strict mode for this validator? I can picture a case where someone needs an RGB string formatted without spaces (or up to 1 space after commas between the numbers, perhaps). For those people this change would not only be a breaking change, but it would make the validator useless.

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).

test/validators.js Outdated Show resolved Hide resolved
@a-h-i
Copy link
Author

a-h-i commented Aug 17, 2022

Could it be useful to have a strict mode for this validator? I can picture a case where someone needs an RGB string formatted without spaces (or up to 1 space after commas between the numbers, perhaps). For those people this change would not only be a breaking change, but it would make the validator useless.

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

@braaar
Copy link
Contributor

braaar commented Aug 18, 2022

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 { strict = true } which does not allow whitespace, and you have to set it to false to allow whitespaces.

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 fix!: allow whitespace between color values in isRgbColor, add strict mode.

@WikiRik
Copy link
Member

WikiRik commented Aug 18, 2022

I agree that we want the default to be false, but I think we can go forward with this PR with strict = true and add a TODO that for the next major release we want to change that behaviour

@a-h-i a-h-i requested a review from WikiRik August 18, 2022 23:09
@braaar
Copy link
Contributor

braaar commented Aug 19, 2022

I agree that we want the default to be false, but I think we can go forward with this PR with strict = true and add a TODO that for the next major release we want to change that behaviour

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.

@WikiRik
Copy link
Member

WikiRik commented Aug 19, 2022

Making a second PR right after this is merged to keep for the next major release would indeed be better. Good point!

@a-h-i
Copy link
Author

a-h-i commented Aug 19, 2022

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?


export default function isRgbColor(str, includePercentValues = true) {
export default function isRgbColor(str, includePercentValues = true, strict = true) {
Copy link
Contributor

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

Copy link
Member

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;

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];
}

Copy link
Author

@a-h-i a-h-i Aug 19, 2022

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? 🙂

Copy link
Contributor

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.

Copy link
Author

Choose a reason for hiding this comment

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

@braaar updated readme

@a-h-i a-h-i requested review from braaar and WikiRik and removed request for WikiRik and braaar August 21, 2022 05:56
options.includePercentValues : true;
} else {
// backward compaitable behaviour
// Defaults
Copy link
Member

Choose a reason for hiding this comment

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

I think we can make the object the default behaviour, as long as the backwards compatible behaviour keeps working this would not be a breaking change. But I'm interested what @braaar and @rubiin have to say about this

Copy link
Contributor

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.

Copy link
Contributor

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

Copy link
Author

Choose a reason for hiding this comment

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

@braaar changed in 9d0d3b3

Copy link
Contributor

@braaar braaar left a 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

README.md Outdated Show resolved Hide resolved
a-h-i and others added 20 commits May 14, 2024 22:33
Co-authored-by: Brage Sekse Aarset <brage.aarset@gmail.com>
Co-authored-by: Brage Sekse Aarset <brage.aarset@gmail.com>
Co-authored-by: Brage Sekse Aarset <brage.aarset@gmail.com>
Co-authored-by: Brage Sekse Aarset <brage.aarset@gmail.com>
Co-authored-by: Brage Sekse Aarset <brage.aarset@gmail.com>
Co-authored-by: Brage Sekse Aarset <brage.aarset@gmail.com>
Co-authored-by: Brage Sekse Aarset <brage.aarset@gmail.com>
Co-authored-by: Brage Sekse Aarset <brage.aarset@gmail.com>
@a-h-i
Copy link
Author

a-h-i commented May 14, 2024

@profnandaa rebased and resolved merge conflicts

Copy link
Member

@profnandaa profnandaa left a 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! 🎉

@profnandaa profnandaa removed the mc-to-land Just merge-conflict standing between the PR and landing. label May 15, 2024
@a-h-i
Copy link
Author

a-h-i commented May 20, 2024

@WikiRik hey, sorry for the ping, I was wondering does it require another review? A bit unclear on the process from here

@WikiRik
Copy link
Member

WikiRik commented May 21, 2024

@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

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

Successfully merging this pull request may close these issues.

isRgbColor does not ignore spaces between params
5 participants