-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
[pickers] Always use props.value
as the source of truth when defined
#16853
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
[pickers] Always use props.value
as the source of truth when defined
#16853
Conversation
bf91819
to
37abb52
Compare
Deploy preview: https://deploy-preview-16853--material-ui-x.netlify.app/ |
d7aec39
to
7714139
Compare
props.value
as the source of truth when defined
804a8f1
to
1977df2
Compare
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 work! 👏 💙
Thank you for taking care of it. 🙏
I've updated my example with use cases that I checked in the original (fields) related PR.
Everyhing seems to check out. 👌
onError: props.onError, | ||
}); | ||
|
||
const timezoneFromDraftValue = valueManager.getTimezone(utils, state.draft); | ||
if (previousTimezoneProp !== timezoneProp) { |
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.
Nice cleanup allowed by refactor. 🙌 💙
if (selectionState === 'shallow') { | ||
setState((prev) => ({ | ||
...prev, | ||
draft: newValue, | ||
clockShallowValue: newValue, |
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.
Yeah... The Time Clock could really use a value management refactor. 🙈
Now, its behavior has to be "declared" in the common state management. 🤷
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.
AFAIK, the only reason why we can't just keep those "shallow" value inside the clock state, is to update the value in the toolbar while dragging, but without calling onChange
.
If we decide that we are fine either:
A. Calling onChange
during the drag
B. Not updating the toolbar during the drag
Then we could get rid of this state altogether.
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.
B. Not updating the toolbar during the drag
Personally, I don't think it's such a bad idea. 🤔
What do you think? 🤔
It might even be more transparent to the user, that they are only selecting (not have already selected) the new value, while dragging.
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 it's very subjective tbh 😆
Given that the clock is used by way less people than before, maybe going for the simpler option makes sense here.
And I agree that it may clear out the expectations.
Hi @flaviendelangle |
Hi, |
Closes #15530
Follow up on #15875