-
-
Notifications
You must be signed in to change notification settings - Fork 83
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
[getAll] Support precision, closes #542 #548
Conversation
❌ Deploy Preview for colorjs failed. Why did it fail? →
|
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 don't think we want a separate parameter here, we'd want to make the second param an options object with space
and precision
as keys. Specifying a color space (either as a string or ColorSpace
object should still work.
Agreed. Done. Could you please have another look? |
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.
Please note that I said:
Specifying a color space (either as a string or
ColorSpace
object should still work.
Using space
as an options param should only be needed when we’re also specifying precision.
Something like this in Lines 69 to 71 in 3f97a65
Where a destructured object is used as a parameter, but then |
I was thinking of something like this, too. Thank you so much for the hint! 🙏 |
This reverts commit 4c52663.
src/getAll.js
Outdated
* @param {string | ColorSpace | object} [options=color.space] If a string or ColorSpace, the color space to convert to. Defaults to the color's current space. | ||
* If an object: | ||
* [options.space=color.space] — the color space to convert to (defaults to the color's current space); | ||
* [options.precision] — the number of significant digits to round the coordinates to. |
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.
It doesn’t seem to me like TypeScript is properly understanding the type here. Maybe making a @typedef
for the function’s options would be best? I can add a code suggestion for that you agree
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.
Yes I think a typedef would make sense here. Though I thought we had found a way to do overloads?
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.
Overloads would work too, but I still don’t think it’s a bad idea to define the options outside of the function’s JSDoc just for readability. We can have one overload with string | ColorSpace
and another with the new type (eg. GetAllOptions
).
Co-authored-by: Adam Thompson-Sharpe <adamthompsonsharpe@gmail.com>
Co-authored-by: Adam Thompson-Sharpe <adamthompsonsharpe@gmail.com>
@MysteryBlokHed, could you please check if I get the idea with overloads right? |
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.
Everything typing-related LGTM!
@DmitrySharabin do you have access to edit the release notes for v0.6.0 to mention this? (make sure not to accidentally publish!) |
It looks like I don't — I don't see any drafts of release notes. |
Ensure that it’s something you had in mind, though. My approach is relatively straightforward. We should probably have an optional
options
parameter withprecision
as a property.