Conversation
| <RangeControl | ||
| <StepperControl | ||
| icon="screenoptions" | ||
| label={ __( 'Height in pixels' ) } | ||
| minimumValue={ minSpacerHeight } | ||
| maximumValue={ sliderSpacerMaxHeight } | ||
| separatorType={ 'none' } | ||
| maxValue={ sliderSpacerMaxHeight } | ||
| minValue={ minSpacerHeight } | ||
| onChangeValue={ changeAttribute } | ||
| value={ height } | ||
| onChange={ changeAttribute } | ||
| style={ styles.rangeCellContainer } | ||
| step={ 20 } |
There was a problem hiding this comment.
This is for testing only. I will revert this before merging.
etoledom
left a comment
There was a problem hiding this comment.
Great job @geriux ! It works and look great ✨
I really like the accessibility solution, feels so natural 👍
I added a few small code comments, but nothing really important.
There's also one extra detail that I think we could improve. When the cell is pressed, it reacts with opacity. Other cells have some logic to this but this one does nothing:
What do you think about passing a disabled=true property down to the cell's base TouchableOpacity and avoid this opacity animation from happening?
| ### separatorType | ||
|
|
||
| Separator type for the `Cell` style. | ||
|
|
||
| - Type: `String` | ||
| - Required: No | ||
| - Platform: Mobile |
There was a problem hiding this comment.
This kind of docs looks great! Thank you for including it.
But this is something I'm not too familiar with, for example:
separatorType is a prop of the base Cell component. As far as I understand, in this file we should document the props that are particular for the stepper component, and inherit properties (even from docs) from the parent component.
Does it makes sense or maybe I'm lost? :)
There was a problem hiding this comment.
I think we should add the docs for the StepperControl instead of StepperCell, because StepperControl is the public API. And for inheriting the docs, it can only be possible if parent view is also part of the public @wordpress/components API. Base Cell is not public and i think it won't be public. If we had long term plans for separatorType I'd suggest adding a public parent view but we want to get rid of that as soon as possible so not sure if it's worth it.
There was a problem hiding this comment.
I think we should add the docs for the StepperControl instead of StepperCell
That's what I thought at the beginning, but I was surprised that there wasn't docs already for StepperControl .
icon and label are also inherited props. Maybe we want to use BaseControl as an abstraction of our base Cell component (and also extract the TextInput logic from it). I don't mean to do this on this PR though, just ideas about how to improve in the future.
There was a problem hiding this comment.
Thanks for the feedback! It makes sense to move the docs to StepperControl and remove the props that are not specific for the component itself. I'll start with that but it's also good to know how we could improve it in the future.
| onAccessibilityAction={ ( event ) => { | ||
| switch ( event.nativeEvent.actionName ) { | ||
| case 'increment': | ||
| this.onIncrementValue(); | ||
| break; | ||
| case 'decrement': | ||
| this.onDecrementValue(); | ||
| break; | ||
| } | ||
| } }> |
There was a problem hiding this comment.
Great solution for accessibility, works like a charm ✨
| /* translators: accessibility text. Inform about current value. %1$s: Control label %2$s: Current value. */ | ||
| _x( '%1$s. Current value is %2$s', 'Increase or decrement to change the value' ), |
There was a problem hiding this comment.
Not sure if we should use _x here.
As far as I understand, _x is used when the same frase might need different translations depending on the context. We do have another instance of this same string, but not sure if the context is different (this is a picker while the other is the slider).
If we keep it, I'd suggest to use a similar context string, something like: Picker for selecting a number inside a range.
There was a problem hiding this comment.
Oh right! we do have the Slider one. I'll change the _x thanks!!
| accessibilityActions={ [ | ||
| { name: 'increment', label: 'increment' }, | ||
| { name: 'decrement', label: 'decrement' }, | ||
| ] } |
There was a problem hiding this comment.
From what I see here, labels for standard actions (like increment/decrement) are not required, but if we add them, the best would be to localise them. I'd suggest to not add them in this case and let the system do their magic.
There was a problem hiding this comment.
Sounds good! Way better to avoid handling those localizations =D
| { | ||
| "title": "StepperCell", | ||
| "slug": "stepper-cell", | ||
| "markdown_source": "../packages/components/src/mobile/bottom-sheet/stepper-cell/README.md", | ||
| "parent": "components" | ||
| }, |
There was a problem hiding this comment.
Not sure if we should add this here 🤔
StepperCell is an internal component that we make available via the native version of StepperControl.
@gziolo any light on this?
There was a problem hiding this comment.
It's interesting that it gets detected. I guess this is how it works with README.md files added to @wordpress/components.
I don't think it's internal as it gets exposed and consumed in the block library. We should just make it clear that it will work only with the React Native code. @youknowriad - any thoughts on how to make it possible to ignore all mobile docs from being exposed in the documentation published at https://developers.wordpress.org?
There was a problem hiding this comment.
I don't think it's internal as it gets exposed and consumed in the block library.
We are currently using the controls abstractions (StepperControl, RangeControl, etc...), so the mobile-only -Cell components are not being consumed by any other libraries (not directly).
We are planning on adding these docs directly to StepperControl instead. Wdyt?
Thank you! I think so too! Tested different methods and this one seemed just right 😁
Good idea! I'll check it out 😃 |
|
@etoledom Updated with some changes =) |
etoledom
left a comment
There was a problem hiding this comment.
Thank you for the update @geriux - It's working great now 🎉
Let's wait for @gziolo and/or @youknowriad to ✅ the documentation bit.
The rest looks good to me. Great job!
Yay! Sounds good! Thank you! 🎉 |
|
I have two very basic questions to better understand the purpose of this new component. What's the difference between this component and See:
Why is it specific to mobile only? |
|
@gziolo Basically we want the Stepper component to represent controls that has ≤ 6 or 8 options instead of Slider on mobile. It is a UX request made by @iamthomasbishop so I'll defer to him to provide better insight about this. |
Yes, as @pinarol mentioned Stepper (or even Picker, which @koke has mentioned) is better suited than a Slider for controls with a small range of options. For example, Apple's HIG suggests the following:
|
|
I opened #19236 to ensure that mobile-only components aren't exposed in WordPress developers' docs. It should make it easier for you to keep all the work documented. |


Gutenberg-mobilePR -> wordpress-mobile/gutenberg-mobile#1640Description
This PR adds a new mobile component
StepperNote: To be able to test this, I've replaced the
SliderControlwith this new componentStepperControl. I'll revert this before merging.To test
SpacerblockHeightusing the stepper controlFor Android devices, users will be able to change the value using the Up / Down volume buttons. It will announce the new value with any change.
For iOS, users will be able to swipe up / down with one finger on the screen to change the value. It will also announce the new value after a change.
Screenshots
iOS
Android
Types of changes
New feature
Checklist: