Set a Color instance's coordinates from a string without new Color(string)

[sidewayss]

Is there a way to set a Color instance's coordinates using a string, they way you can when you instantiate a Color, but without creating a new Color instance? Is there a way to do that via some subset of the parse() function? The idea is to workaround new Color() because this is a library with no dependencies. I am currently faking it with new colorInstance.constructor() and passing in the string that way.

[LeaVerou]

I think it would help to elaborate a bit on what problem you’re trying to solve. E.g. parse() sounds like it would work for your use case, but it sounds like it doesn't?

[sidewayss]

I want to use parse() without the new Color() because I don't want to create a dependency with Color.js. The context is an animation library that animates colors across one or more elements. Each animation object takes a single Color instance (like Color.js it maintains a single color space per object). If the animation applies to multiple elements, the code gets the current DOM value for each element and converts it to numeric coordinates for this object's color space.

So, it takes a DOM CSS string value (element.style or getComputedStyle() - note that getComputedStyle() converts to rgb() and other spaces sometimes, depending on the browser), and converts it to a set of 3 coordinates. I want to do that without a dependency on Color.js. As I stated, I currently fake it with colorInstance.constructor(), which is kinda goofy, but it should work fine.

[LeaVerou]

I still don't understand the problem well — how would you use Color.js without introducing a dependency on Color.js?

If you're talking about not introducing a dependency in terms of user-facing API, that’s easy: you can just use the tree-shakeable API: https://colorjs.io/docs/procedural
Note that you'll have to register all the color spaces you are interested in manually for this to work as expected.

[sidewayss]

I use Color.js without the dependency because users pass in a Color instance. All I want is to be able to say something like:

colorInstance.coords = "color(display-p3 1 0.5 0)";

though that would obviously require another property name.

The tree-shakeable API also requires an import dependency that I'd prefer to avoid, and I don't see a way to use parse() without creating a new Color instance. Maybe I should be calling parse() directly instead of new Color, but I don't see a way to do that without an import. Again, I can work around this easily enough, it just strikes me that there might be a way to parse the string and return coordinates in a specified space instead of a new Color instance (and of course it would have to include the alpha).

[LeaVerou]

I’m sorry, I want to help, but I still don’t understand the use case. 😭

Let’s suppose Color.js had a magic() function that allowed you to do:

colorInstance.coords = magic("color(display-p3 1 0.5 0)");

Wouldn’t you still have to import that function from Color.js? How would you use anything from Color.js without an import? 🤔

I don't see a way to use parse() without creating a new Color instance.

Not sure if that's the root of the confusion, but the tree-shakeable API does not use Color instances at all, it uses object literals.

[sidewayss]

If I import parse() the code would look like this, right?

const color2 = parse(string);
color1.setAll(color2.space, color2.coords);

Regarding setAll(): is there a way way to include the alpha, not just the coords?

[sidewayss]

I took a peek at the code for setAll() and it does not handle the alpha. Looks like including alpha would require adding an alpha argument and one line of code (assuming that the alpha property rejects invalid/undefined values and there's no need to validate here):

color.alpha = alpha;

[lloydk]

Again, I can work around this easily enough, it just strikes me that there might be a way to parse the string and return coordinates in a specified space instead of a new Color instance (and of course it would have to include the alpha).

Based on this statement it sounds like the to function will do what you want.

const color2 = to(string, "srgb");

or

const color2 = to(string, color1.space);

The to() function will return an object literal that contains the space, coords, and alpha properties (The Typescript type for this object literal is a PlainColorObject).

If you'd like color2 to be a Color object then you can do

const color2 = Color.to(string, color1.space);

[sidewayss]

@lloydk thanks for the suggestion. I had considered to(), the same way I had considered parse(), but I want to avoid the import dependency. As I stated originally, I want to do something like this:

color.value = string;
array = [...color.coords, color.alpha];

And, as I stated, I can work around it with the slightly funky:

color2 = new color1.constructor(string);
color1.setAll(color2.space, color2.coords);
array = [...color1.coords, color2.alpha];

Though, based on your suggestion I could write it this way, which is definitely more compact:

color2 = color1.constructor.to(string, color1.space);
array = [....color2.coords, color2.alpha];

I opened this discussion topic to see if there was any cleaner way to do it without the import, and it looks like @lloydk's suggestion is as good as it gets. If there is a simple way to add a setter to Color.prototype that accomplishes this I would consider writing that code and submitting the PR, if it's desirable - obviously it could be written using parse() or to(), in which case it would be easy to write. But I get the sense that it is not desirable because I'd be the only one using it - let me know if I'm wrong on that. Thanks to you all for considering my question.

[LeaVerou]

To reiterate in case my earlier wording was confusing: parse() when called by itself, and not as Color.parse(), does NOT return a Color instance, it returns an object literal. It will not have any methods, just three properties: space, coords, alpha.

ALL Color.js methods can be imported and used individually and then you don't deal with a Color class, ever. That's what the tree-shakeable API is about. Same with setAll(), if you import it by itself, you can just call it like setAll(colorObj, [...]) where colorObj is a simple object literal. Same with to() actually, you can either use the OO API as color.to(space) or the procedural API as to(colorObject, space).

I still don't understand how you expect to be able to use any function from a library without importing at the very least that method. Like, in my example earlier with the magic() method, how do you picture this working without doing something like import {magic} from ...? I suspect it's some other constraint you're trying to avoid and you're just wording it incorrectly, but unless you can describe what the actual constraint is, I'm not sure how to help 😕

WRT setAll() not setting alpha, that is an API design issue that should be discussed separately.

[sidewayss]

@LeaVerou - Thanks for continuing to try :) I have definitely learned about the difference between Color.parse() and Color.to() versus parse() and to() via this discussion. I don't think I need any further help. I'm going to go with a version of the last snippet of code in my last comment. Here it is again:

color2 = color1.constructor.to(string, color1.space);
array = [....color2.coords, color2.alpha];

That snippet illustrates exactly how I do this without importing anything, all because the user provides me with color1, their Color instance. It might be considered clumsy to use instance.constructor like that, but it works perfectly well. I was looking for an even more direct way of doing it, but I got to improve it with Color.to(), so I'm satisfied.

As for the separate discussion about setAll() not setting alpha, I can open that discussion if you are interested in having it. It's not of great importance to me at this time, I was simply figuring things out and thinking out loud. To my outsider ear setAll() sounds like it should include everything, but it's actual meaning is within the context of your library, about which I know not very much.

[LeaVerou]

I’m 100% sure that you can do this in a better way, but I need to understand the constraints to recommend specific code. At this point I’m very curious too 😁

Re:setAll() I probably agree (since it's meant to set everything that set() can) but it would need to be discussed separately.

[sidewayss]

Well, constraints are all self-imposed in this case, for what that's worth. This is a javascript library that allows doing more extreme animations, e.g. multiple timing functions, one for each of the three color parameters. In fleshing out the ability to animate colors, it struck me that I should allow users to use Color.js objects and avail themselves of the extended set of color spaces in their animations, as well as the ability to convert their CSS to other color spaces for purposes of animation (via each space's unique interpolation of changing values - did I use "interpolation" correctly there?).

This library has no external dependencies at this time, and I am just trying to avoid adding one. I would be adding the only external dependency so that I could write a couple of lines of code differently, in a library that is not focused specifically on color. But this is a personal project and I can do whatever I want. I'm open to being convinced to add a dependency to Color.js, so give it your best shot.

I am relatively new to javascript, and know next to nothing about building distribution packages with npm, pnpm, or yarn. I am learning everything as I go and haven't gotten there yet, though I hope to get there in the next couple of months. That's just some additional context regarding my ignorance and phobia of external dependencies here.

I'll open a discussion on setAll() - would that be in the Ideas category?

[LeaVerou]

Ohhhh I see, so you want your library to support Color instances if passed, but not actually import Color.js!
Heh, that's yet another case of why we need weak dependencies in JS.

So you’re not actually trying to avoid the Color instance, a Color instance is all you have in that case!
Did I get it right?

I'll open a discussion on setAll() - would that be in the Ideas category?
Sure!

[sidewayss]

You got it right. Does that mean you don't think I can do this in a better way anymore?

I'll open that discussion in Ideas before the day is out.

[LeaVerou]

Btw I should have said earlier I also like avoiding too many dependencies, so I get it (that's why Color.js has no dependencies 😁 ). That's why I want to help :)

So to sum up the use case, you have color1 which is a Color object, and color2 which is a string, and you want to set color1’s coords and alpha from (the parsed form of) color2 after it's converted to color1’s color space, right?
Yeah, I think the way you're doing it is not actually too bad. 😁

[lloydk]

This library has no external dependencies at this time, and I am just trying to avoid adding one. I would be adding the only external dependency so that I could write a couple of lines of code differently, in a library that is not focused specifically on color. But this is a personal project and I can do whatever I want. I'm open to being convinced to add a dependency to Color.js, so give it your best shot.

You may not think you have any external dependencies right now but you have tied your library to objects that conform to portions of the Color.js api. So at some point the Color.js library will have to be bundled into an app using your library either by you or users of your library.

I have a side project where I initially decided I didn't want to tie myself to a specific color library and I was going to create adapters for different javascript color libraries. I very quickly realized that was going to make things incredibly complicated and decided to go with Color.js as the color library for my project.

[sidewayss]

at some point the Color.js library will have to be bundled into an app using your library either by you or users of your library

So what do you suggest that I do? And is "bundle" the same as "package" in the npm context? Or are you talking about some other kind of bundling?

[sidewayss]

I think I can relate a bit to your side project experience - I was just reminded of something I bumped into few months back: getComputedStyle() regularly converts a CSS property's color space to integer-only rgb(), or sometimes to other spaces when you use color(). It varies by browser, maybe other local factors. If the HTML specifies the element's color value via an external rule, not the element's style property, the only reasonable way for me to get that value is getComputedStyle().

So at a minimum I need a way to convert back to the user's original color function/space. Long story short, I have functions to convert from rgb to all the CSS color spaces, but it might well be simpler and generally better to always use Color.js for conversions.

[sidewayss]

I dug up my codepens on style and getComputedStyle() from a few months ago:
hsl() & hwb() are just flavors of rgba()
color(), color-mix(), x-gradient() values

Now my memory is fully refreshed. It's hsl and hwb that are converted to integer rgb (using the now deprecated rgba function and it's old comma-separated syntax). It happens in element.style too, not just getComputedStyle(). And getComputedStyle() reduces color-mix to a single color(), in addition to the conversion of hsl/hwb to srgb. If the property is set directly in the element's style attribute, then the original value is available by parsing element.getAttribute("style"). If not, parsing a stylesheet is tedious.

If all I need to maintain in my library is the minimum of rgb to hsl/hwb conversion (along with converting hex and named colors to rgb), that's not too bad, and I can let Color.js be an option for users that already import it and provide me with an instance. The color-mix() situation is still weird though.

[sidewayss]

So to sum up the use case, you have color1 which is a Color object, and color2 which is a string, and you want to set color1’s coords and alpha from (the parsed form of) color2 after it's converted to color1’s color space, right?

Effectively that's correct. The detail being that the goal is to collect the coords + alpha (in color1's color space) for each element in a 2D array by element. The user provides a single Color instance representing the color space for this animation target.

They can also provide an array of Color instances (of any space) as a stand-in for the actual DOM values (animations generally start from an element's current value, but some jump to a new value at the start of playback). That's the case where I convert the color space id to snake_case so that I can use it as a property name. It's still simpler than using setAll() :)