-
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
RangeControl reset behavior seems wrong #4420
Comments
I can confirm this behavior. When the Reset button is clicked, the slider handle changes position and the underlying value that is sent to the block preview changes, but the number in the input field does not get updated. |
I'm experiencing the same issue. Looking at the code I think I see the issue. First the This will make the slider update its position. However, the value for number input does not update. It appears that is being set to The slider value updates correctly because it is being set to |
Since this is tagged as low priority and I wanted to includes the reset option for a slider used in a block in my plugin, I copied the code and created a custom component to import into the block. I did have to tweak how the dependencies were imported. I also had to make a minor tweak on how the control was being exported, but, with the change mentioned in my last reply, the slider with a reset works quite well. I'm quite happy since my js experience is limited to doing some basic jQuery stuff. |
I can confirm the issue as well in version 5.1. This behavior is weird and should be corrected. |
I'm gonna give this a try! |
I can't reproduce this issue, also tested in the playground and it works fine. https://wordpress.github.io/gutenberg/?path=/story/components-rangecontrol--with-reset |
It seems the doc regarding this control has changed substantially since I last looked: There was no documentation or mention of having to Since the usage docs now has an example: I'll see if I can use it now following those instructions. This is my custom control which is basically just a copy of the core RangeControl but with a working reset, just for the record ;). Doesn't use |
Closing as this seems fixed. |
I'm still very confused by all of this. Right now I have a Option 1 The issue is if the user decides to delete the numbers before putting in a new number, as soon as all the numbers are deleted, the Video: https://cloudup.com/cXB3RIx3iOz Option 2 Video: https://cloudup.com/csH16pb5aPL Is there a way to know the user hit the Reset button? If so, that'd solve my problem. Any advice is appreciated. |
@TwisterMc I can see how the behavior can be confusing. I think this went through several iterations already; @ItsJonQ might be able to shed some lights here and confirm whether or not we need to improve the behavior. |
Is what I'm seeing "correct" then? I feel there are usability issues both ways, but if one is technically correct, then that'd be good to know. |
Hai there 👋 ! @TwisterMc Thank you for your examples! I had helped refactor this component several months ago. I'll admit, some of the I recently submitted a PR to help resolve regressions + add stability: I just pushed an update to address some of the reset confusion:
However, I don't think it 100% address this issue, or your question re: Option 1 vs Option 2. Between the 2 options, Option 1 would be the better solution, for now. Like @kmgalanakis pointed out in the original description, it should reset to an initial value (avoiding the controlled component -> uncontrolled component swap). The component should manage it by itself, then pass back the results. Once my PR gets merged, I'll take a look at this more closely. Hope this helps! |
Haii! I'm starting to look into this one! I would love thoughts/confirmation on some scenarios 🙏 (Note: This is NOT how it currently works. However, this is how I'd expect it to work) Controlled: No initial valueconst [state, setState] = useState()
const handleOnChange = next => setState(next)
<RangeControl allowReset value={state} onChange={handleOnChange} />
Note: Reason for Controlled: With initial valueconst [state, setState] = useState(10)
const handleOnChange = next => setState(next)
<RangeControl allowReset value={state} onChange={handleOnChange} />
Controlled: With initial value and
|
@ItsJonQ Thanks for the details here, I'm not familiar with the existing behavior in Gutenberg but I suspsect that in some use-cases we want the "reset" to mean (reset to "null"/undefined) I guess this is doable by passing a
Can we instead call onChange( undefined ) in this case and do the magic to use |
We could! However, As part of this, I think it'll be worth looking into the core blocks where RangeControl + reset is used to get a sense of things 👍 |
How is that different than "" though? For me if the parent don't want to interpret the reset value, it should provide one. |
I think this issue is no longer relevant with all the changes in the components, including the range control and how resetting the values work. Please feel free to reopen otherwise 🙏 |
When having a
RangeControl
withallowReset
set totrue
even though the click of the reset button is resetting the value, the control is not behaving correctly.I can see two possible behaviors. As soon as the user clicks
Reset
the control should either return to its default value, in my case-1
or it should return to its previously saved value.Instead, the control remains at the state prior to the reset, even though its actual value is changed.
The text was updated successfully, but these errors were encountered: