[DateRangePicker] New option to open range picker by pressing end adornment (like other pickers)

[acgrant]

Duplicates

• [x] I have searched the existing issues

Latest version

• [X] I have tested the latest version

Summary 💡

There was talk about a similar idea in https://github.com/mui/material-ui/issues/24511#issue-789968923 which pertained to the DatePicker. It would be nice to see this functionality in the the Pro Plan's DateRangePicker. I understand there is the disablePointerEvents prop which allows focus to shift; however, for accessibility purposes I believe that having the calendar pop up after clicking the calendar icon, like with the case of the DatePicker component, would be nice.

Examples 🌈

No response

Motivation 🔦

I was able to get close to the functionality by using the renderInput prop alongside two TextFields, each with InputProps and then the following:

 InputProps={{
           endAdornment: (
             <InputAdornment position='end'>
             <IconButton onClick={customFunctionThatOpensTheDateRangePicker} edge='end'>
                <DateRangeIcon />
               </IconButton>
            </InputAdornment>
          ),
 }}

It was pretty effective. I had to add a ClickAwayListener to address some things; however, I was fine. Then, I discovered that the mobile view buttons for "cancel" and "ok" were not responsive because I had overwritten the open prop on the DateRangePicker and thus (at least according to my current understanding) would have to account for all the other changes of state myself. That's when I realized how nice it would be for this to just be built in. I'm sure it comes with some unique challenges; however, if you can't see a concise workaround for me or if you feel it's worth it, I would be very appreciative.

[alexfauquette]

Hi @acgrant could you share a codesandbox (here is maybe a good starting point) such that we can be sure we are talking about same package versions, and see all the modification you are talking about and get a better idea about what you are trying to achieve

[acgrant]

@alexfauquette Got you, I whipped something up here: https://codesandbox.io/embed/basicdaterangepicker-demo-mui-x-forked-gqyiw1?fontsize=14&hidenavigation=1&theme=dark

You can click the calendars to open the DateRangePicker and click away to close them. You can also click the calendar again to close them. It's just a rough implementation to give you the idea I was shooting for. The biggest issue I ran into however, and one which isn't reproducible in the code sandbox is the degraded functionality in the browser for mobile environments. Like I explained above, the popup calendar is different for mobile and thus all the click functionality breaks down ("ok" and "cancel" are the buttons I believe and they are no longer responsive once I tamper with the open prop on the DateRangePicker).

[alexfauquette]

Thanks for the reproduction. The problem is the use of ClickAwayListener which catch the click before action bar button get access to the event.

In fact, you do not need it. You have onClose and onOpen callback which will be called when the Popper/Dialogue needs to be open/closed

Here is your example without the ClickAwayListener. At the top of demo.jsx you have IS_MOBILE variable to switch easily between DesktopDateRangePicker and MobileDateRangePicker https://codesandbox.io/s/basicdaterangepicker-demo-mui-x-forked-kdp5cz?file=/demo.tsx

[acgrant]

@alexfauquette You are awesome, I missed those properties. Your guidance made all the difference, thank you.

[acgrant]

@alexfauquette Hey Alex, clicking the endAdornment for the endDate changes focus to the startDate. So, clicking the endDate's endAdornment will only open up the end if something is selected for the startDate. I realize this is perhaps intentional since you want to encourage the user to follow a certain workflow; however, I thought it worthy of mention since this isn't the behavior when merely clicking into either input. For instance, I can click in the endDate text field and focus will shift to it and the same goes for startDate but if I click the endDate adornment, focus shifts to the startDate. I believe it is solved by having the focused prop depend on a change in state, but once again, just wanted to make mention of it.

[alexfauquette]

Yes, I do not see how you could control if the user is editing the start or the end day of the range

[acgrant]

@alexfauquette What is the main reason that clicking the endDate's endAdornment doesn't open up the endDate? I just want the Date Range Picker to respond to either one of the end adornments being clicked in the same way that clicking the actual input would. disablePointActions on the endAdornment prop in InputProps comes close; however, it doesn't open the date modal.

Even if I use the open prop, like we've discussed, alongside disablePointActions, it seems like there is some underlying functionality in the prop that favors opening the start date for editing, even if the focus is in the endDate input. Is this a bug or is there a viable workaround?

You can see what I'm talking about by looking at the sandbox you sent me. If, from a fresh load, you click the endAdornment for the endDate, it doesn't open up the endDate for editing (the focus and value is instead shifted to the start date).

[alexfauquette]

The reason comes from the management of the state currentlySelectingRangeEnd. This naming is bad, but basically it can be either 'start' or 'end'. and it's this state value that indicates if the range picker is currently selecting a start date or an end date.

This state is not exposed yet, so you can not control this aspect fo the component.

About why it's possible to open picker on end date when clicking on the second input, the answer is here

const openRangeStartSelection = () => {
      if (setCurrentlySelectingRangeEnd) {
        setCurrentlySelectingRangeEnd('start');
      }
      if (!readOnly && !disableOpenPicker) {
        openPicker();
      }
};

const openRangeEndSelection = () => {
      if (setCurrentlySelectingRangeEnd) {
        setCurrentlySelectingRangeEnd('end');
      }
      if (!readOnly && !disableOpenPicker) {
        openPicker();
      }
};

The two inputs are get props onClick=openRangeStartSelection and onClick=openRangeEndSelection

I do not think their is a viable workaround for now

I reopen the issue such that we can track this special case

[acgrant]

The reason comes from the management of the state currentlySelectingRangeEnd. This naming is bad, but basically it can be either 'start' or 'end'. and it's this state value that indicates if the range picker is currently selecting a start date or an end date.

This state is not exposed yet, so you can not control this aspect fo the component.

About why it's possible to open picker on end date when clicking on the second input, the answer is here

const openRangeStartSelection = () => {
    if (setCurrentlySelectingRangeEnd) {
      setCurrentlySelectingRangeEnd('start');
    }
    if (!readOnly && !disableOpenPicker) {
      openPicker();
    }
};

const openRangeEndSelection = () => {
    if (setCurrentlySelectingRangeEnd) {
      setCurrentlySelectingRangeEnd('end');
    }
    if (!readOnly && !disableOpenPicker) {
      openPicker();
    }
};

The two inputs are get props onClick=openRangeStartSelection and onClick=openRangeEndSelection

I do not think their is a viable workaround for now

I reopen the issue such that we can track this special case

Thank you for the detailed response and for reopening the issue. Yeah, I saw the odd naming choice as well. I do like how descriptive the names are but the currentlySelectingRangeEnd: 'start' | 'end'; you mentioned, through me off, as well.

So, what are your thoughts on how it could be rectified? Are you thinking about exposing a new slice of state pertaining to currentlySelectingRangeEnd (or perhaps a more aptly named prop)?

[stldo]

So, is there no way to know if the start or the end date is being selected? Do you have an estimate of when this feature will be available?

[acgrant]

So, is there no way to know if the start or the end date is being selected? Do you have an estimate of when this feature will be available?

@stldo I've asked where it is in their timeline, but haven't gotten any conclusive answer back yet. But yeah, to answer your question, no it doesn't have that state exposed so there's no workaround for the use case I proposed.

[LukasTy]

This is a topic directly related to https://github.com/mui/mui-x/issues/5549. Solving the linked issue would result in solving this one as well. For these reasons, I have removed this issue from the Needs grooming board.