Closed DharmiVekariya closed 3 weeks ago
There is a hook you can use, but that is from the internal utils: useDefaultDates
This needs to be used inside of the LocalizationProvider
context so it does not work outside of it. Example:
import * as React from 'react';
import { DemoContainer } from '@mui/x-date-pickers/internals/demo';
import { LocalizationProvider } from '@mui/x-date-pickers-pro/LocalizationProvider';
import { AdapterDayjs } from '@mui/x-date-pickers-pro/AdapterDayjs';
import { DateRangePicker } from '@mui/x-date-pickers-pro/DateRangePicker';
import { useDefaultDates } from '@mui/x-date-pickers/internals';
function DemoComponent() {
const defaultDates = useDefaultDates();
console.log('default Dates: ', defaultDates);
return null;
}
export default function BasicDateRangePicker() {
return (
<LocalizationProvider dateAdapter={AdapterDayjs}>
<DemoContainer components={['DateRangePicker']}>
<DemoComponent />
<DateRangePicker localeText={{ start: 'Check-in', end: 'Check-out' }} />
</DemoContainer>
</LocalizationProvider>
);
}
[!CAUTION] Since this is an internal hook using it might break your implementation in the future. The reason behind this is that we do introduce breaking changes in the internal folders, since it is not meant to be public.
:warning: This issue has been closed. If you have a similar problem but not exactly the same, please open a new issue. Now, if you have additional information related to this issue or things that could help future readers, feel free to leave a comment.
@DharmiVekariya: How did we do? Your experience with our support team matters to us. If you have a moment, please share your thoughts in this short Support Satisfaction survey.
@DharmiVekariya, could you explain your use case in more depth?
What are you trying to achieve? 🤔
Why do you need access to the default
values? Shouldn't you need access to the actual values for it to make sense? 🤷
There is a hook you can use, but that is from the internal utils:
useDefaultDates
This needs to be used inside of the
LocalizationProvider
context so it does not work outside of it. Example:import * as React from 'react'; import { DemoContainer } from '@mui/x-date-pickers/internals/demo'; import { LocalizationProvider } from '@mui/x-date-pickers-pro/LocalizationProvider'; import { AdapterDayjs } from '@mui/x-date-pickers-pro/AdapterDayjs'; import { DateRangePicker } from '@mui/x-date-pickers-pro/DateRangePicker'; import { useDefaultDates } from '@mui/x-date-pickers/internals'; function DemoComponent() { const defaultDates = useDefaultDates(); console.log('default Dates: ', defaultDates); return null; } export default function BasicDateRangePicker() { return ( <LocalizationProvider dateAdapter={AdapterDayjs}> <DemoContainer components={['DateRangePicker']}> <DemoComponent /> <DateRangePicker localeText={{ start: 'Check-in', end: 'Check-out' }} /> </DemoContainer> </LocalizationProvider> ); }
Caution
Since this is an internal hook using it might break your implementation in the future. The reason behind this is that we do introduce breaking changes in the internal folders, since it is not meant to be public.
It will work for me. Thank you for the quick response.
@DharmiVekariya, could you explain your use case in more depth? What are you trying to achieve? 🤔 Why do you need access to the
default
values? Shouldn't you need access to the actual values for it to make sense? 🤷
@LukasTy, my use case involves adding custom validations to the MUI Date Picker. By default, the date picker allows selecting years from 1900 to 2099, but if a user manually enters a date outside this range, such as before 1900 or after 2099, it triggers minDate and maxDate errors.
In my application, I can't use static year boundaries for validation because the allowed range might change in future updates of the MUI library. To avoid having to modify the code each time, I need access to the default date boundaries from the library itself, so I can dynamically compare dates without hardcoding limits.
Alternatively, it would be helpful if MUI provided a separate error type specifically for range validation, instead of combining it with minDate and maxDate. In some cases, the date picker may have its own minimum or maximum date, and combining these checks can be difficult to manage, requiring additional code to maintain separate validations.
In my application, I can't use static year boundaries for validation because the allowed range might change in future updates of the MUI library. To avoid having to modify the code each time, I need access to the default date boundaries from the library itself, so I can dynamically compare dates without hardcoding limits.
@DharmiVekariya I'm not sure about the severity of this assumption. 🤔
The sole reason why we have predefined min and max dates is the YearCalendar
, which does not support virtualization. Given the implementation of this component, it could end up being too slow to handle a longer span of years.
Based on the above data—I don't think we'd ever change those default dates.
The only thing that we'd love to find the capacity for is changing the implementation of YearCalendar
to work properly without any min
and max
dates, thus creating a need for you to refactor your code. 🙈
WDYT about using explicit minDate
and maxDate
values?
If you have no specific value to define—feel free to use the same values that we set.
This would avoid the need to rely on internals that "can break tomorrow in a patch release". 🤔 🤷
Or am I missing some use case, which would not be covered by the described solution?
Steps to reproduce
I need suggestion how to I get min and max date from LocalizationProvider in my component? I need those date for further validation in my app.
Current behavior
No response
Expected behavior
No response
Context
No response
Your environment
No response
Search keywords: X-DatePicker