-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NumberControl: Add custom spin buttons #45333
Changes from 8 commits
7b790e0
016f253
4938546
2cc5953
80335a2
f15a653
e5967b3
50c011e
e63d7ed
d1e2a98
c056f5c
393218c
6120b3b
d1cc602
6e9be91
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -2,23 +2,28 @@ | |
* External dependencies | ||
*/ | ||
import classNames from 'classnames'; | ||
import type { ForwardedRef } from 'react'; | ||
import type { ForwardedRef, ChangeEvent } from 'react'; | ||
|
||
/** | ||
* WordPress dependencies | ||
*/ | ||
import { forwardRef } from '@wordpress/element'; | ||
import { isRTL } from '@wordpress/i18n'; | ||
import { isRTL, __ } from '@wordpress/i18n'; | ||
import { plus as plusIcon, reset as resetIcon } from '@wordpress/icons'; | ||
|
||
/** | ||
* Internal dependencies | ||
*/ | ||
import { Input } from './styles/number-control-styles'; | ||
import { Input, SpinButton } from './styles/number-control-styles'; | ||
import * as inputControlActionTypes from '../input-control/reducer/actions'; | ||
import { add, subtract, roundClamp } from '../utils/math'; | ||
import { ensureNumber, isValueEmpty } from '../utils/values'; | ||
import type { WordPressComponentProps } from '../ui/context/wordpress-component'; | ||
import type { NumberControlProps } from './types'; | ||
import { HStack } from '../h-stack'; | ||
import { Spacer } from '../spacer'; | ||
|
||
const noop = () => {}; | ||
|
||
function UnforwardedNumberControl( | ||
{ | ||
|
@@ -36,6 +41,9 @@ function UnforwardedNumberControl( | |
step = 1, | ||
type: typeProp = 'number', | ||
value: valueProp, | ||
size = 'default', | ||
suffix, | ||
onChange = noop, | ||
...props | ||
}: WordPressComponentProps< NumberControlProps, 'input', false >, | ||
ref: ForwardedRef< any > | ||
|
@@ -178,14 +186,27 @@ function UnforwardedNumberControl( | |
return nextState; | ||
}; | ||
|
||
const buildSpinHandler = | ||
( direction: 'up' | 'down' ) => | ||
( event: ChangeEvent< HTMLInputElement > ) => { | ||
let nextValue = isValueEmpty( valueProp ) ? baseValue : valueProp; | ||
if ( direction === 'up' ) { | ||
nextValue = add( nextValue, baseStep ); | ||
} else if ( direction === 'down' ) { | ||
nextValue = subtract( nextValue, baseStep ); | ||
} | ||
nextValue = constrainValue( nextValue ); | ||
onChange( String( nextValue ), { event } ); | ||
}; | ||
|
||
return ( | ||
<Input | ||
autoComplete={ autoComplete } | ||
inputMode="numeric" | ||
{ ...props } | ||
className={ classes } | ||
dragDirection={ dragDirection } | ||
hideHTMLArrows={ hideHTMLArrows } | ||
hideHTMLArrows={ size === '__unstable-large' || hideHTMLArrows } | ||
isDragEnabled={ isDragEnabled } | ||
label={ label } | ||
max={ max } | ||
|
@@ -200,6 +221,37 @@ function UnforwardedNumberControl( | |
const baseState = numberControlStateReducer( state, action ); | ||
return stateReducerProp?.( baseState, action ) ?? baseState; | ||
} } | ||
size={ size } | ||
suffix={ | ||
size === '__unstable-large' && ! hideHTMLArrows ? ( | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The big thing we need to decide before merging is this part! While I do think the current logic makes sense, I also feel like the big spin buttons should be disabled by default 🤔 They take up a lot of space, so I'm afraid many use cases would prefer to disable them unless they were particularly useful for the specific case. On the other hand, this API could get super messy with the The middle ground I can think of is to update the API so There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Switching Another option is to remove Let me know—happy to defer to you and @ciampo. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. A
Cool. @ciampo ^ We'll go with this if you don't have any objections. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sounds good to me — just to make sure, we will still show these custom, larger spin buttons only for the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I changed my mind 😅 I started working on this and in the process appreciated how many instances of So I went ahead and implemented a I think this makes sense. Let me know if you disagree! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, that makes sense 👍 I really appreciate the effort and care you put into working out the best solution! |
||
<> | ||
{ suffix } | ||
<Spacer marginBottom={ 0 } marginRight={ 2 }> | ||
<HStack spacing={ 1 }> | ||
<SpinButton | ||
icon={ plusIcon } | ||
isSmall | ||
aria-hidden="true" | ||
aria-label={ __( 'Increment' ) } | ||
tabIndex={ -1 } | ||
onClick={ buildSpinHandler( 'up' ) } | ||
/> | ||
<SpinButton | ||
icon={ resetIcon } | ||
isSmall | ||
aria-hidden="true" | ||
aria-label={ __( 'Decrement' ) } | ||
tabIndex={ -1 } | ||
onClick={ buildSpinHandler( 'down' ) } | ||
/> | ||
</HStack> | ||
</Spacer> | ||
</> | ||
) : ( | ||
suffix | ||
) | ||
} | ||
onChange={ onChange } | ||
/> | ||
); | ||
} | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -4,10 +4,13 @@ | |
*/ | ||
import { css } from '@emotion/react'; | ||
import styled from '@emotion/styled'; | ||
|
||
/** | ||
* Internal dependencies | ||
*/ | ||
import InputControl from '../../input-control'; | ||
import { COLORS } from '../../utils'; | ||
import Button from '../../button'; | ||
|
||
const htmlArrowStyles = ( { hideHTMLArrows } ) => { | ||
if ( ! hideHTMLArrows ) return ``; | ||
|
@@ -28,3 +31,9 @@ const htmlArrowStyles = ( { hideHTMLArrows } ) => { | |
export const Input = styled( InputControl )` | ||
${ htmlArrowStyles }; | ||
`; | ||
|
||
export const SpinButton = styled( Button )` | ||
&&& { | ||
color: ${ COLORS.ui.theme }; | ||
} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I wonder how common this styling is going to be. A similar one is the unit dropdown in UnitControl. Do you happen to know any others? Hoping this will remain a one-off 😂 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure, sorry! It's very possible I misunderstood the design and the + / - buttons are supposed to be tertiary (link) buttons and not regular buttons that have the theme's accent colour. Do you know @jasmussen? |
||
`; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a blocker for this PR to land, but have you considered hooking these buttons up to the reducer system that is already in place? Having the buttons dispatch the
pressUp
/pressDown
actions would dedupe the logic and would also add the Shift key enhancement.I'm guessing that would involve moving the spin buttons down into the InputControl component, and some re-plumbing. Unclear whether it's worth the effort though. cc @stokesman and @ciampo who I'm sure have stronger ✨ feelings ✨ about the reducer construct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did try a few different approaches here but couldn't figure out anything that felt right.
NumberControl
as thedispatch
function inInputControl
isn't available.NumberControl
as the existing reducer state inInputControl
isn't available.InputControl
to have the spin button functionality since it is supposed to be a generic input. (The docs say it's intended to be an eventualTextControl
replacement.)So I ended up settling on this boring repetitive approach. I can DRY it up a bit further by making the reducer and spin buttons use the same logic. I've done that in e63d7ed.
Let me know if you have any other suggestions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the thing — InputControl already contains a lot of the scaffolding that seems generic but basically only makes sense for number inputs (drag gestures, arrow key handlers). One can argue that spin buttons are just as generic as up/down arrow key handlers are. I guess in its current state, it's really a
<input type="potentially anything, extend me!">
control rather than a strict<input type="text">
control.Some other things I'm thinking in relation to this:
This line in Storybook will error when using the big spin buttons. Is that a problem?
gutenberg/packages/components/src/number-control/stories/index.js
Line 35 in 19186e5
The
isPressEnterToChange
prop currently does not behave as expected when drag gestures and up/down keys are involved. When we fix this logic at some point, will we also have to fix the big spin buttons separately?So, on the surface it kind of seems like things will generally be simpler if make the big spin buttons "generic" (wink wink) and move them down into InputControl.
But in any case, I think this PR is DRY enough for the time being, and it wouldn't be hard to extract the buttons if we feel like it in the future. (We should look at that
event.target.validity.valid
thing before merging though)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It does yet it seems wrong to me. Instead of putting any more effort into fitting that mold my feeling is
InputControl
ought to be broken into a hook + component combo. That would allowNumberControl
to use the hook and get direct access todispatch
for more flexible extensibility. It would also allow makingInputControl
more generic. I have an old experimental branch doing that and I'd been thinking to make a fresh start on it afterNumberControl
was converted to TS. Now, I'm not sure when I'll find the time to do so.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not necessarily related to the immediate changes that this PR may need to make in order to be merged relatively soon — but my general feeling is also that
InputControl
could/should be simplified:InputControl
, while it would make sense to me if they were part ofNumberControl
isPressEnterToChange
prop is necessary at allThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see 😅 thanks for the discussion.
It's easier to move the custom spinners from
NumberControl
toInputControl
later in a BC way than it is to do the opposite, so I'm personally inclined to stick with putting them inNumberControl
at least for now.Good catch. I'll fix this by overriding
event.target
to be the<input>
. We do this already for the drag events.I would expect that setting
isPressEnterToChange
should only make it so thatonChange
is not called while the user is typing a number and should not have any effect on the spin controls, no?Yeah not a huge fan of this reducer pattern. I don't really see why
InputControl
couldn't be a standard managed component with callback props for each of the actions (onPressDown
,onPressUp
, etc.)