Add helper for setGradientObject

[chasedavis]

The getGradientObject return value of useColorPicker is great. To take that value and then re-load it into a gradient would be super as well -- this would make saving/loading flows quite simple as opposed to calling all of the individual setters.

This would be the preferred re-usable pattern where the picker is not used for CSS but shaders etc.

[hxf31891]

@chasedavis could you give me an example here?

[chasedavis]

@hxf31891

let's say that I store a gradient object somewhere:

const gradientObject = getGradientObject()

And then I store that gradient object (which is a key value pair) in a database. Then, when I fetch the object from the db, I'd want to initialize the component with the object form:

<ColorPicker value={gradientObject} />

or alternatively, though less ideal, cast it to css first:

const gradientCSS = setGradient(gradientObject)
return (
  <ColorPicker value={gradientCSS} />

if you're using this picker for shaders as I am, then the css isn't actually needed, so being able to go straight to key-value and retrieve from it with a helper api would be great!

In summary: the library provides a path from css --> object, but not object --> css as far as I can tell.

edited for clarity

[PierreAtUptale]

I agree with @chasedavis regarding the current difficulty of working with this library for picking colors that are not meant to be stored as CSS color strings.

Another aspect that complicates the matter and that will need to be taken into account during conversion from object to CSS, as mentioned here, is that the library relies on uppercase keys in the CSS gradient screen to track which color key is currently active for color selection. The conversion needs to preserve this selection logic.

[hxf31891]

@chasedavis @PierreAtUptale I am following now, great idea. Will work out asap.

[hxf31891]

@chasedavis @PierreAtUptale take a peak at 2.2.26, definitely experimental but in my testing so far it will accept an object as the initial value.

A few notes:

1. the object must follow the same structure as the one created by getGradientObject (see below)
2. the picker still returns a css string, this would be a breaking change for most users. You can however use the above mentioned function (getGradientObject) to convert that string to an object and either feed back to the picker or save to your DB, you can see an example about midway in the readme using the function.
3. @PierreAtUptale's comment about capitalization is true, but if not is capitalized it will default to the first color (first being lowest left). If y'alls needs require having a specific color selected on start, an easy work around would be to use the setSelectedColor function also included in the useColorPicker hook.

Would love to hear back from you guys as to wether this is helpful, any suggestions, bugs etc.

example object gradient { "gradientType": "linear-gradient", "degrees": "40deg", "colors": [ { "value": "rgba(27,107,235,1)", "left": 0 }, { "value": "rgba(25,245,157,1)", "left": 100 } ] }

example object solid { "gradientType": null, "degrees": null, "colors": [ { "value": "rgba(27,107,235,1)" } ] }

[PierreAtUptale]

@hxf31891

@PierreAtUptale's comment about capitalization is true, but if not is capitalized it will default to the first color (first being lowest left). If y'alls needs require having a specific color selected on start, an easy work around would be to use the setSelectedColor function also included in the useColorPicker hook.

Do you mean that the following input gradient object would have the picker select the 2nd color key as the selected color?

{
  "gradientType": "linear-gradient",
  "degrees": "40deg",
  "colors": [
    {
      "value": "rgba(27,107,235,1)",
      "left": 0
    },
    {
      "value": "RGBA(25,245,157,1)", // Notice the capitalization
      "left": 100
    }
  ]
}

I'm concerned that if a user interacts with the color picker using only a gradientObject, they won't have the ability to control the selection of the color. In this scenario, the picker would default to the first color key, without providing an option to choose a different one.

Though if your answer to my question is "yes", then that means that we can handle key selection from the gradient object and that's not a problem anymore. 🙂

[hxf31891]

@PierreAtUptale the answer to your first question is yes, the second color would be selected.

And your conclusion is also true.

Lastly, they could use the UI to switch between gradient points which will still work correctly even if the initial value was all lowercase.

Let me know if either of you guys get a chance to try this out and if it is helpful.

[PierreAtUptale]

Let me know if either of you guys get a chance to try this out and if it is helpful.

@hxf31891 I'd love to give it a try, though I can't find the tag 2.2.26 that you mentioned.

[hxf31891]

@PierreAtUptale sorry for the long delay here. If you are still interested those changes are included in the recently released v3.