Calcite-components: Enhancement: Rename 'color' component to 'color-picker'.

Created on 1 Jan 2021 · 12Comments · Source: Esri/calcite-components

Description

For consistency and specificity, I think we should rename the color component to color-picker.

We should also consider renaming its child components.

calcite-color-hex-input => calcite-input-color-hex. // input first since it's an input component.
calcite-color-swatch => calcite-color-picker-swatch. If this could ever be used outside of this component then I would propose calcite-color-swatch.

Question(s)

Should we also create an input that launches this color picker? @julio8a is that in the plans? Something like calcite-input-color-picker?

Acceptance Criteria

calcite-color is consistent with calcite-time-picker and calcite-date-picker.

Relevant Info

Which Component

calcite-color

Example Use Case

NA.

4 - verified breaking change convention discussion enhancement

Source

driskull

All 12 comments

Follow-up questions:

Are we no longer using the main color-picker component name in supporting ones? E.g., calcite-color-picker-<support-component-name>
Does this need to be a breaking change? I thought we would deprecate calcite-color when calcite-color-picker is introduced.
I'd propose using calcite-hex-input vs calcite-input-color-hex since the pickers aren't following this convention: calcite-<thang>-picker instead of calcite-picker-<thang>
Could you add more info regarding the acceptance criteria? I'm not clear on how it should be consistent with other pickers.

Should we also create an input that launches this color picker? @julio8a is that in the plans? Something like calcite-input-color-picker?

For MVB, I was working w/ @mitc7862 on an inlined color component and he hashed out designs for a more generic component. I think it makes sense to add to this repo to allow this UX for other cases and not only color. I'll create an issue for it this week.

jcfranco on 5 Jan 2021

Are we no longer using the main color-picker component name in supporting ones? E.g., calcite-color-picker-

I think we can do that if hex will only be used by color picker.

Does this need to be a breaking change? I thought we would deprecate calcite-color when calcite-color-picker is introduced.

If we do it when we move to the new repo then it isn't a breaking change.

Could you add more info regarding the acceptance criteria? I'm not clear on how it should be consistent with other pickers.

Sure, we will have calcite-date-picker and calcite-time-picker. We will also have calcite-input-date-picker which is the inline input that opens the date picker.

driskull on 5 Jan 2021

I'd propose using calcite-hex-input vs calcite-input-color-hex since the pickers aren't following this convention: calcite--picker instead of calcite-picker-

If it's an input component, it might make more sense for the input to be first. That will allow us to group the input components and have consistency there. However, if it would only be used internally then there might be an exception here.

driskull on 5 Jan 2021

I think the "input that launches the color picker" (with the preview swatch, that Mitch had specced) is valid as a "calcite-input-*", but that's separate from the current "hex input" correct?