You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was just thinking the other day that I should make explicit in the API Reference that it's a convention throughout the Culori API for methods to return undefined when they can't produce a valid color, and that a chain of methods, eg. formatHex(hsl(rgb('tomato'))) should not break on unparseable strings.
This makes it nicer to code in environments where you primarily work with expressions, such as Observable notebooks, but also in regular code, where you can casually insert your own parsers or other fallbacks:
constmyColor=culori.parse(string)||myFancyParser(string)||culori.rgb('#0000');if(myColor){// do something with `myColor`}
I don't believe parsing an invalid string should throw (and it wouldn't have much useful feedback other than that the string is not understood), but I will look into throwing TypeErrors when the API is invoked with the wrong types of arguments. (Also JSDoc / TS type definitions #128 may help with IDE autocompletion).
It would also maybe make sense to have a way to switch the whole API from the return undefined paradigm to be throw-based.
@danburzo ah ok I get it. But maybe having a isValid() method then?
I am working on a class that uses culori, I want to make sure all the colors that are passed in, can be parsed.
It would be very practical, if parse would throw an error if it was not successful in parsing a color.
The only way I can do this now is check for
undefined
.I'd find it very practical to get something like:
The text was updated successfully, but these errors were encountered: