React-datepicker: `openToDate` not working in `v0.41.1`

Created on 13 Feb 2017  路  24Comments  路  Source: Hacker0x01/react-datepicker

Currently the prop openToDate does not seem to work in v0.41.1.
See, for example, https://hacker0x01.github.io/react-datepicker/#example-25

In my opinion, the bug is an unintended consequence of commit 418b8d33594b72f97f05c2ba37558305a969ad24 which introduced the preSelection prop in Calendar (https://github.com/Hacker0x01/react-datepicker/commit/418b8d33594b72f97f05c2ba37558305a969ad24#diff-53b2cf631ea5d028d238854eaa70ce16R107) that is filled with today if no date is selected hence if (initialDate) is always true.

bug

All 24 comments

I'm working on a PR.
I think we can remove the openToDate prop on the calendar due to the preSelection prop and move the validation, handling and test cases to the datepicker class.

Thanks for looking into this.
Are you planning to remove openToDate?
I found it really convenient for showing a (multi-month) inline calendar which stylistically matches the datepickers used in other places of the application. Actually, I am directly using the Calendar component now to show the inline calendar without using the DatePicker with the inline prop set to true. Is this use "supported" (potentially, at least) or discouraged?

Wanted to know if there was any word on openToDate or a work around to get that functionality? I see that setting selected works but I don't want to have the field pre-selected. Thanks

Any news on the fix for openToDate ? Thanks !

I found a quick fix (for now) just downgrading the version to v. 0.40.0

aha yes, i just did that too ! ;)

Hmm, it seems 0.41 introduced some regressions that weren't in 0.40. Hopefully someone is able to find the root cause, so this can be fixed.

@donysukardi That's still not quite right. The default should not be outside the selectable range. (And it didn't used to be in 0.39.)

It should at least take minDate and maxDate into account. (I don't know whether it used to take excludeDates into account too as I didn't use that prop.)

So is it merged to 0.44? I see it's still not working.

Guys, any update? PR is merged but did not work

@alex-shamshurin It works for me at https://hacker0x01.github.io/react-datepicker/#example-26 with both Chrome 58 and Firefox 48.5.

In what way is it not working for you?

In inlined mode with portal and monthShown it doesnt't work. It always opens on selected date. This is my config

this.currentTime = moment()
....
<ReactDatePicker
        ref={this.saveRef}
        locale='ru'
        inline={isMobile}
        popoverTargetOffset='10px -50px'
        minDate={this.minDate}
        maxDate={this.maxDate}
        highlightDates={highlightDates}
        onChange={this.onChange}
        onSelect={this.onSelect}
        onClickOutside={this.onSelect}
        todayButton='today'
        selected={input.value}
        openToDate={currentTime}
        withPortal={withPortal}
        monthsShown={isMobile ? 3 : 2}
        customInput={!isMobile ?
          <InputField
            {...this.props}            
            currentTime={currentTime}/> : null}
          />

I don't know how portal or monthShown might be relevant, but selected takes priority over openToDate, and I think that is correct.

You can see that behavior in the example actually. When you first open it (and no date is selected), it will open to 1993-09-28. If you select some other day, say 1993-12-25, then the open it again, it will open to the selected date rather than losing your place.

No, I think it's different. select is an actual value of the widget, internal current date. But openToDate is the date to which widget will scroll when it's opened. For example selected may be some date at future, but every time datepicker is open it must be opened at today, I think THIS is correct.

Agreed with @alex-shamshurin: I think it makes sense that openToDate should override selected if specified, otherwise the date opened should be selected. Without that behavior I don't think there's a combo of parameters that would make sense to achieve opening to a different date.

Yep, Our real example - user selects some departure date in some months in future, say on June, then he decided to select another date, but next time datepicker shows June and next 2 months (we use portal and inlined version with 2 months shown). So user cannot choose this month! and go to another ticket service.

So it must be opened everytime at openToDate date.

Hmm, to me the use case of providing a default date to open to seems like it would be way more common than wanting to override the behavior of opening to the selected date. It also appears to have been the original intention per #320 and #486.

I expect changing the behavior would be a breaking change for almost everyone who is already using openToDate -- assuming they followed the example code.

@alex-shamshurin If I understand your use case, you still do want the selected date to show on the calendar, but you want it to show on the rightmost month rather than on the left, correct? Or would you want the datepicker to open to April even if a date in December is selected?

The current behavior of multiple months does seem kind of weird to me. https://hacker0x01.github.io/react-datepicker/#example-30 If you click a day on the right hand month then re-open the calendar again, the months will have shifted. Is that what you're trying to work around?

@rafeememon I guess for me the first question is: Is that something that needs to be achievable via a simple combination of props? And if so, should we be redefining what the openToDate prop means? If we do want to redefine it, should we go through a deprecation period where we emit warnings for anyone who is currently using it in a way that would beak?

I'm also having a hard time even thinking of how opening to a non-selected date should behave for the user. For example, for selected=2017-12-20 and forceOpenToDate=2017-02-15, what should happen when the user presses left arrow to select the previous day? Should that select 2017-12-19, or 2017-02-14? If the former, which month should the calendar display at that point? If the later, wouldn't that be a problem for accessibility?

I guess a lot of it will come down to what the expected use case actually is.

I want that selected date must be selected date )). And the openToDate must be the date on which calendar will open. No matter right or left or whatever. Selected may be today, but I want calendar to be opened at the openToDate date (may be 30 year before today or last age). OpenToDate it's just like a scroll position.

Is that what you're trying to work around
yes

Is there any update?

@martijnrusschen The #860 is still not merged.. Could you check it out?

Merged, thank you.

Should be fixed now?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

kkras3 picture kkras3  路  3Comments

formigone picture formigone  路  3Comments

dhruvparmar372 picture dhruvparmar372  路  3Comments

ahribori picture ahribori  路  3Comments

evolve2k picture evolve2k  路  3Comments