mui / mui-x

MUI X: Build complex and data-rich applications using a growing list of advanced React components, like the Data Grid, Date and Time Pickers, Charts, and more!
https://mui.com/x/
4.08k stars 1.26k forks source link

[pickers] How do I get default min and max date from `LocalizationProvider`? #14414

Closed DharmiVekariya closed 3 weeks ago

DharmiVekariya commented 3 weeks ago

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.

image

Current behavior

No response

Expected behavior

No response

Context

No response

Your environment

No response

Search keywords: X-DatePicker

michelengelen commented 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.

github-actions[bot] commented 3 weeks ago

: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.

LukasTy commented 2 weeks ago

@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? 🤷

DharmiVekariya commented 1 week 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.

It will work for me. Thank you for the quick response.

DharmiVekariya commented 1 week ago

@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.

LukasTy commented 1 week ago

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?