-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
[docs] New page for TimeClock
#7280
Conversation
70fb8d3
to
f8e26ee
Compare
|
||
const props = useThemeProps({ | ||
props: inProps, | ||
name: 'MuiTimeClock', | ||
}); | ||
|
||
const { | ||
ampm = false, | ||
ampm = utils.is12HourCycleInCurrentLocale(), |
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 added a smart fallback to be consistent with the picker behavior
I can extract this breaking change to a standalone PR if you want.
Note that it's a breaking change only for direct usage of TimeClock
, not for TimePicker
and DateTimePicker
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'd say just go with adding it in this PR.
I reckon that barely anyone was using the standalone Clock component.
But I do still think that we should include a breaking change item in migration guide as well as a changelog entry. The example should probably reference the original component name (was it Clock
?) as well..? 🤔
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.
The old name was ClockPicker
I'll add it to the migration guide 👍
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.
Added
These are the results for the performance tests:
|
f8e26ee
to
9d78b92
Compare
9d78b92
to
6864255
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.
LGTM, just agreeing with the breaking change and so it would be great to update migration guide at the same time. 👌
|
||
const props = useThemeProps({ | ||
props: inProps, | ||
name: 'MuiTimeClock', | ||
}); | ||
|
||
const { | ||
ampm = false, | ||
ampm = utils.is12HourCycleInCurrentLocale(), |
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'd say just go with adding it in this PR.
I reckon that barely anyone was using the standalone Clock component.
But I do still think that we should include a breaking change item in migration guide as well as a changelog entry. The example should probably reference the original component name (was it Clock
?) as well..? 🤔
Doc preview
What's next ?
Date Range Calendar
pageDate Range Picker
andDate Time Picker
pages