-
-
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
[pickers] Clean component interfaces and remove non-implemented props #4758
Conversation
These are the results for the performance tests:
|
@@ -96,13 +96,42 @@ interface DateStateAction<DraftValue> { | |||
skipOnChangeCall?: boolean; | |||
} | |||
|
|||
interface PickerStateProps<TInputValue, TValue> { | |||
export interface PickerStateProps<TInputValue, TValue> { |
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.
Copy paste of the descriptions in BasePickerProps
extends ExportedCalendarPickerProps<TDate>, | ||
ExportedClockPickerProps<TDate> { | ||
ExportedClockPickerProps<TDate>, | ||
Omit<PickerStatePickerProps<TValue>, 'onDateChange'> { |
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.
We don't pass onDateChange
to the toolbar in CalendarOrClockPicker
so I did not put it in the interface.
Instead the toolbar receives an onChange
callback that is a small wrapper adding the variant arg.
I am in favor of removing this wrapper variant param in onDateChange
, in which case we could just pass it to the toolbar and remove the onChange
wrapper.
|
||
export interface BaseToolbarProps<TDate> | ||
export interface BaseToolbarProps<TDate, TValue> |
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 generic so that the date
prop of BaseToolbarProps
can be correctly typed with TValue
(the prop will be renamed parsedValue
in #4736)
@@ -2,6 +2,7 @@ | |||
"props": { | |||
"onChange": { "type": { "name": "func" }, "required": true }, | |||
"renderInput": { "type": { "name": "func" }, "required": true }, | |||
"value": { "type": { "name": "arrayOf", "description": "Array<any>" }, "required": true }, |
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 understand why value
was not in the proptypes
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 reducing type confusions!
Closes #4557
In this PR
onClose
/onOpen
andclose
props from the static pickersusePickerState
whenever possible rather than redefining its propsToolbarComponent
prop fromBaseDateRangePickerProps
(not implemented, see [DateRangePicker] ToolbarComponent prop documented but not implemented #4557)toolbarPlaceholder
prop fromBaseDateRangePickerProps
andBaseTimePickerProps
(not implemented)toolbarFormat
prop fromBaseTimePickerProps
(not implemented)What's next ?
componentsProps.toolbar
to avoid all this prop drilling