-
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
[RNMobile] Stepper component #18864
[RNMobile] Stepper component #18864
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is for testing only. I will revert this before merging.
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.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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).
_x( '%1$s. Current value is %2$s', 'Slider for picking a number inside a range' ), |
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good! Way better to avoid handling those localizations =D
docs/manifest-devhub.json
Outdated
{ | ||
"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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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 =) |
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.
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-mobile
PR -> wordpress-mobile/gutenberg-mobile#1640Description
This PR adds a new mobile component
Stepper
Note: To be able to test this, I've replaced the
SliderControl
with this new componentStepperControl
. I'll revert this before merging.To test
Spacer
blockHeight
using 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: