`HslaColor` parsed to zero in hue value

[bjarnef]

We have something like this in a color picker wheere hue value is changed from a hue slider:

const newColor: HslaColor = {
      h: element.value,
      s: this.saturation,
      l: this.lightness,
      a: this.alpha / 100,
};

this.setColor(newColor);

Inside setColor() function:

  setColor(colorString: string | HslaColor) {

    const colord = new Colord(colorString);

    const { h, s, l, a } = colord.toHsl();

    this.hue = h;
    this.saturation = s;
    this.lightness = l;
    this.alpha = this.opacity ? a * 100 : 100;

    const hslaColor = colorString as HslaColor;

    // Workaround as hue isn't correct after changing hue slider, but Colord parse hue value as zero when color is black.
    if (hslaColor && hslaColor.h) {
      this.hue = hslaColor.h;
    }
    
    this._colord = colord;
    ...
}

Hue value from HslaColor object is e.g. 191, but after parsing in to Colord instance and use toHsl() it returns a hue of 0.
I added a workaround if the parameter is an HslaColor object and then use in this h property instead, which has the value 191.

[dkryaklin]

This is expected mathematical behavior

When s: 0 or l: 0, the color is achromatic (gray or black). There is no hue information in the resulting RGB value — { h: 191, s: 0, l: 0 } and { h: 45, s: 0, l: 0 } both produce identical RGB (0, 0, 0), so the hue is unrecoverable on the way back

Your workaround is actually the correct pattern for color pickers: maintain hue state separately and don't rely on the library to preserve it through a round-trip when saturation or lightness hits 0. This is standard practice: native browser color pickers and tools like Figma all do the same thing internall