-
-
Notifications
You must be signed in to change notification settings - Fork 274
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
Date picker component #1499
Date picker component #1499
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,93 @@ | ||
import * as React from 'react'; | ||
|
||
import { TextField } from '@mui/material'; | ||
|
||
import { LocalizationProvider } from '@mui/x-date-pickers/LocalizationProvider'; | ||
import { DesktopDatePicker, DesktopDatePickerProps } from '@mui/x-date-pickers/DesktopDatePicker'; | ||
import { AdapterDayjs } from '@mui/x-date-pickers/AdapterDayjs'; | ||
import { createComponent } from '@mui/toolpad-core'; | ||
import { Dayjs } from 'dayjs'; | ||
|
||
export interface Props extends DesktopDatePickerProps<string, Dayjs> { | ||
format: string; | ||
separator: string; | ||
fullWidth: boolean; | ||
variant: 'outlined' | 'filled' | 'standard'; | ||
size: 'small' | 'medium'; | ||
sx: any; | ||
} | ||
|
||
const resolveFormat = (format: string, separator: string) => format.replaceAll(' ', separator); | ||
|
||
function DatePicker(props: Props) { | ||
return ( | ||
<LocalizationProvider dateAdapter={AdapterDayjs as any}> | ||
<DesktopDatePicker | ||
inputFormat={resolveFormat(props.format, props.separator)} | ||
{...props} | ||
renderInput={(params) => ( | ||
<TextField | ||
{...params} | ||
fullWidth={props.fullWidth} | ||
variant={props.variant} | ||
size={props.size} | ||
sx={props.sx} | ||
/> | ||
)} | ||
/> | ||
</LocalizationProvider> | ||
); | ||
} | ||
|
||
export default createComponent(DatePicker, { | ||
argTypes: { | ||
value: { | ||
typeDef: { type: 'string' }, | ||
onChangeProp: 'onChange', | ||
onChangeHandler: (newValue: Dayjs, { format, separator }: Props) => { | ||
return newValue.format(resolveFormat(format, separator)); | ||
}, | ||
defaultValue: '', | ||
defaultValueProp: 'defaultValue', | ||
}, | ||
format: { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Currently, the Toolpad app developer decides for every user which format they have to input dates in. I wonder if it rather makes more sense that users input the date in the format based on their locale There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I'm not really sure how that would work if say 2 users with different locales edited app, which one should be used? Or is there a possibility that DD-MM-YYYY on one machine might get converted to MM-DD-YYYY on the other? Also what if I don't want to use my locale because I'm building an app for users in a different locale? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Each user in the locale of their browser. The
Those end users will have their browsers set to their own locale, so if the date input just follows that, then it should be fine. What if I build applications for users in mixed locales? e.g. like in MUI: I, in Belgium should see "31/12/2022", and someone in US should see
Which user, the app editor? or the end user? in any case, we can always do both options, default to "use end user locale" and allow overriding with a custom format (and we can probably consolidate the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
When I use datePicker.value in a text field somewhere do we display raw value or formatted with locale? If formatted - do we check all values if it matches date string or shall we also use some meta data from datepicker field to know that we are dealing with date value?
Do I understand correctly that you'd like to have There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I believe we should keep this value unformatted. i.e. a shorthand version of ISO8601 should be fine (
It's an option yes, my preference would be free form text, leave empty to use end user locale, default empty. But we can iterate on the idea. |
||
typeDef: { | ||
type: 'string', | ||
enum: ['DD MM YYYY', 'YYYY MM DD', 'MM DD YYYY'], | ||
}, | ||
defaultValue: 'YYYY MM DD', | ||
}, | ||
separator: { | ||
typeDef: { | ||
type: 'string', | ||
enum: ['-', '/', ' '], | ||
}, | ||
defaultValue: '-', | ||
}, | ||
// @ts-ignore no idea why it complains even though it's done exactly same as TextField | ||
defaultValue: { | ||
typeDef: { type: 'string' }, | ||
defaultValue: '', | ||
}, | ||
label: { | ||
typeDef: { type: 'string' }, | ||
}, | ||
variant: { | ||
typeDef: { type: 'string', enum: ['outlined', 'filled', 'standard'] }, | ||
defaultValue: 'outlined', | ||
}, | ||
size: { | ||
typeDef: { type: 'string', enum: ['small', 'medium'] }, | ||
defaultValue: 'small', | ||
}, | ||
fullWidth: { | ||
typeDef: { type: 'boolean' }, | ||
}, | ||
disabled: { | ||
typeDef: { type: 'boolean' }, | ||
}, | ||
sx: { | ||
typeDef: { type: 'object' }, | ||
}, | ||
}, | ||
}); |
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.
For uniformity, I prefer to keep the convention of
I prefer to not ad hoc update the signature of
onChangeHandler
until we have more compelling use-cases to do so.I think we should standardize on
toISOString()
for the format ofvalue
andnewValue
, so that the developer doesn't have to consider the formatting when handling this date.for a benchmark, refer to retool
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.
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.
onChangeHandler
. We can implement the logic in the component itself, where we have access to the live property values. Similar to how we doonSelectionChange
in theDataGrid
regarding
onChangeHandler
, this is a remnant from a time when we were still very optimistic we would be able build the components library by just taking all the bare MUI components and wrapping each of them withcreateComponent
. In the meantime it has become clear that we needed more customization on most components. Or components that don't exist in MUI at all. And so theonChangeHandler
has become a bit obsolete. Maybe we should even think about getting rid of it altogetherThere 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 had that initially done, however using value of datePicker in other places resulted in raw iso string which seemed wrong to me. But sure we can do that
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 can use the date-only form of ISO8601. This is also unambiguously usable as input for
new Date()