Property value converter for Eye Dropper Color Picker

[konius]

Umbraco version

v8

Description

Currently Eye Dropper Color Picker returns object in the ModelsBuilder and no meaningful context what the colour is.

Would be great to return a custom Model with a range of various properties to work with:

public class EyeDropperColorPickerModel
    {
        [JsonProperty("rgba")]
        public long[] Rgba { get; set; }

        [JsonProperty("hsla")]
        public double[] Hsla { get; set; }

        [JsonProperty("rgbString")]
        public string RgbString { get; set; }

        [JsonProperty("rgbaString")]
        public string RgbaString { get; set; }

        [JsonProperty("hslString")]
        public string HslString { get; set; }

        [JsonProperty("hslaString")]
        public string HslaString { get; set; }

        [JsonProperty("hex")]
        public string Hex { get; set; }

        [JsonProperty("alpha")]
        public double Alpha { get; set; }
    }

How can you help?

No response

[bjarnef]

It could probably implement a custom property editor using DefaultPropertyValueConverter similar to ColorPickerValueConverter: https://github.com/umbraco/Umbraco-CMS/blob/v8/contrib/src/Umbraco.Core/PropertyEditors/ValueConverters/ColorPickerValueConverter.cs

Currently it just store an object, but storing it a string (or another type) would probably be considered as a breaking change.

Not sure we want to store all the additional data you suggest, where it may be better/simpler to store an JSON object.

There are however ways vai C# or JavaScript to get alpha, convert hex > rgba, rgba to hex(a), etc. A JavaScript solution could be to use TinyColor

Most developers probably don't need more than just the color code: hex or rgba. If you do need this I would suggest creating a custom property editor using the <umb-color-picker> component. That way you have full control or the return type.

The events returns tinyColor object: https://github.com/umbraco/Umbraco-CMS/blob/d428a4543f33bb7094cf7db5f6b6fdc2d1de3063/src/Umbraco.Web.UI.Client/src/common/directives/components/umbcolorpicker.directive.js#L179-L221

https://github.com/umbraco/Umbraco-CMS/blob/d428a4543f33bb7094cf7db5f6b6fdc2d1de3063/src/Umbraco.Web.UI.Client/src/views/propertyeditors/eyedropper/eyedropper.controller.js#L24

so you have access to methods listed here, e.g getAlpha(): https://github.com/bgrins/TinyColor

[konius]

Yes, I agree that all of it is not needed, it's just an example, but object is not a nice "object" to work with and to make any use you need to null check, cast ToString() or make any use of it or ensure that it starts with # and so on.

The data type offers controls for alpha, but later you need to write your own implementation to figure stuff out.

The current implementation seems only to cater for the editor, but not for the developer who would be using it in the C# or Razor code.

Could we not continue storing the string as the value, but use ConvertSourceToIntermediate for further processing?

[bjarnef]

It could convert to value to a string, but would be a breaking change, although it probably won't break in most cases if using color?.ToString(), but some might have implemented logic expected the type to be an object.

Sure the ConvertSourceToIntermediate could process to value and convert hex to rgb(a) etc. an return a more complex object, but it would add more overhead, while most probably don't need it.

In that case, why not store these data as JSON instead as the tinyColor already has logic to store the data as a more complex object with alpha, hex, rgba. Some may even prefer to split each channel in properties: R, G, B, A, etc.

@nul800sebastiaan do you have some input of how HQ wants this? I think this should either be implemented in a custom property editor or a more advanced color picker, but I think that would fit in a package instead.

[konius]

Yes, totally agree that it doesn't need all the things in the example. It needs as minimum as possible, but also I think an object doesn't give any information for the developer writing the code. Is it a hex, does it have # in front, does it not, what was the alpha level, what's the best way to manipulate it to get something out of it.

There was never an issue with storing and returning the id as string or integer of content or media, but convenience led to returning IPublishedContent which has autocomplete or even the actual model so an object in my opinion is just going back.

So although you're right about everything, in my opinion it's not an elegant implementation currently and custom logic will be needed to figure out basic information about the stored data each time.

[nul800sebastiaan]

Unfortunately, Bjarne is completely correct, adding a PVC now would be a breaking change for everyone who's already querying and converting the values for this editor. Unfortunately we didn't think of this at the time. We encourage you to do your own convertor, or as suggested a custom editor with convertor. Sorry for the inconvenience. 🙁