ColorPalette: make component more resilient to color entries with same color value and/or name

[ciampo]

What problem does this address?

Initially flagged and discussed in #43096

While working on separate issues, I noticed that the ColorPalette component can receive a list colors where two or more color entries can have the same value (e.g #ffffff).

When this happens, currently the ColorPalette component is not able to correctly highlight as "selected" the color that was actually picked by the user — instead, it highlights all color entries sharing that same value as "selected":

(image taken from this comment

Having different entries sharing the same color value (and potentially even the same color name) should be considered as a totally valid scenario:

• Scenario n. 1: there's an entry named Text with value #000000, and another entry called ButtonText with value #000000
• Scenario n. 2: The theme defines an entry with name Primary and value #ff0000. The user then also defines an entry with the same and same value

This means that the ColorPalette component should not attempt to introduce any logic to alter the list of color entries in order to mitigate this issue, as that could result in an unexpected behavior to the user.

What is your proposed solution?

While there isn't a commonly agreed solution yet, one way to look at this issue is to make sure that the data representing the color entries (passed to ColorPalette) is improved in a way that makes each color entry uniquely identifiable, even if it shares the same name and value as another entry (e.g. an id prop).

I can only imagine that this wouldn't be a trivial change, since it would involve potentially changing the schema of the data, and making sure that the id is generated correctly regardless of how the color is added to the list of available colors for a site (e.g. via the global styles UI, by editing theme.json...).

Since I'm not very knowledgeable about this part of the Gutenberg app, I'll let other folks chime in and discuss potential solutions (I'll keep an eye in case the conversation involves the ColorPalette component)

[ciampo]

Tagging:

• @andrewserong @aaronrobertshaw @ramonjd as I believe they are much better fitted than I am to (hopefully) find a good solution to this issue
• @jasmussen and @mtias for overall awareness of this issue

[ramonjd]

I can only imagine that this wouldn't be a trivial change, since it would involve potentially changing the schema of the data, and making sure that the id is generated correctly regardless of how the color is added to the list of available colors for a site

It could be tricky 🤔🤔🤔🤔🤔🤔

I assume we only want to transform data in the editor JS so that the UI controls behave (?)

I'm just thinking aloud... we could add unique keys in global-styles/hooks, where we build the colors object, e..g,

		if (
			shouldDisplayDefaultColors &&
			defaultColors &&
			defaultColors.length
		) {
			result.push( {
				name: _x(
					'Default',
					'Indicates this palette comes from WordPress.'
				),
				// Add a unique id
				colors: defaultColors.map( ( item, index ) => ( {
					...item,
					key: `${ item.color }-${ index }`,
				} ) ),
			} );
		}

But then how would we determine whether the color is "selected" based on the value, when the only value we store is the raw color?

Maybe, at the same time we store the selected color value, store a separate stringified color object as the "selected" color {key: '#000-1', color: '#000', slug: 'Doug' }

I'm not sure this is a good idea, but if anything better occurs to me I'll repost.