Components: require string value for ColorPalette
's newColor
onChange
value
#46890
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Related to #46358
Update
ColorPalette
'sonChange
prop to require a string for itsnewColor
parameter, rather than optionally accepting one.Why?
While working on the above refactor, I encountered type conflicts with
ColorPalette
'sonChange
, because this method'snewColor
parameter was optional, and could therefor beundefined
. WithinColorListPicker
the relatedonChange
values are all strings or arrays of strings.While we could type the parameters in
ColorListPicker
'sonChange
asstring | undefined
I thought it was worth revisiting whyColorPalette
introduces and optional/undefined value in the first place.It appears this parameter is optional to accommodate
ColorPalette
'sclearColor
method, which passesundefined
as the new color value.That works fine, but I do wonder if "optional" is the best approach for the parameter... there is a second parameter (
index
, also optional) for theonChange
- so omittingnewColor
while includingindex
would cause a collision, theindex
would be interpreted asnewColor
and chaos would ensue. This probably isn't likely to occur in practice, but it does look like a potential issue/edge case that could slip past TypeScript.That logic leads me to think that
string | undefined
would be more appropriate than an optionalnewColor
parameter.Going back to the refactor that initially triggered this however, I do think we can eliminate the
undefined
option altogether and haveclearColor
pass an empty string instead. This doesn't appear to break any functionality or tests that I can see, and will simplify the typing of both components.Curious what others think (cc @mirka @ciampo)
How?
First, update the
newColor
parameter's type from an optional string to a required one, then replace the use ofundefined
whenclearColor
is invoked with an empty string.Testing Instructions
ColorPalette
component in StorybookclearColor
method we've updatedTesting Instructions for Keyboard
In the editor, with a paragraph block focused, press
Tab
five times, which will navigate you to the font color option.Press
Space
Press
Tab
at least once to navigate to a color.Press
Space
to select the color. PressSpace
again to deselect it.