Color.js is very error-happy
Opened this issue · 1 comments
While errors are nicely informative, this makes it annoying to develop UIs that use it (including components), where there are often intermediate states with incorrect values (e.g. a user is in the middle of typing a color, or a color channel is set before the color space is).
Case in point that finally prompted me to post an issue: this PR
For things like the color constructor, throwing makes sense and is helpful. But e.g. does it make sense here?
- https://github.com/color-js/color.js/blob/main/src/getColor.js#L16 (can easily happen as an intermediate state)
Line 268 in d49b1ae
- Getting a coordinate: https://github.com/color-js/color.js/blob/main/src/get.js#L8 via https://github.com/color-js/color.js/blob/main/src/space.js#L349
Perhaps we should have some kind of opt-in mode for these errors? Or just warn? A warning serves the same purpose, and is less disruptive to calling code.
If you don't mind me chiming in. While there exist methods such as CSS.supports('color', yourQuestionableColor)
I found that various color values would produce a true without being parsable. Something like isValid/canParse would surely be a big help here. Unfortunately Colorjs is currently wired to immediatly throw errors if a color fails to parse.
Would you recommend i need to write this into a promise to avoid this problem?