Editing an existing range without resetting it

[danieldenbraven]

Hi everyone, we were updating an old application that used an early version of the daterangepicker that had a certain workflow to selecting the range, similar to what you would find for example on the Lufthansa website. Once we upgraded to the latest version, it seems that if you already have a range selected and you click anywhere on the calendar (especially if newDate > startDate) the whole range gets reset and the day you clicked becomes the start date.

Was there a specific reason or a usability aspect to changing this? This becomes quite difficult for users to manage if you want to edit a date range from 01.03.2023 - 10.03.2023, for example, and then click on 13.03.2023 to extend the range with 3 days, but the whole thing resets and the new start date is 13.03.2023. Is there a suggestion on how to change this behaviour? Looking at the code, seems a bit difficult to do without a fork.

[dangrossman]

It's been 8 years since version 2 of this library came out. I do not recall the "why" of anything that old any longer. If you prefer the old behavior, you can continue using the old code. It's just a couple dozen lines of code that renders a calendar. Zero of the releases were security updates. There's no harm in staying with the version you liked.

[danieldenbraven]

Unfortunately moment.js has some security issues and we're "forced" to upgrade to the latest version, which means we need to also upgrade the daterangepicker. The very old version (1.3.*) doesn't work with latest moment from what I saw.

Anyhow, everything works with the upgrades, it's just that the workflow is different to what users are used to normally (some airlines or AirBnb use the 1.* way, Google flights a different way, Skyscanner is identical to daterangepicker) and it's causing some friction but they will get used to it.

I would guess that a pull request to change the behaviour on clickDate when editing an existing range would not make sense/be approved considering how may people use this and that it's been working like this since 2015.

Anyhow, thanks for all the work on the library, was great to see that the upgrade from a version from 7 years ago worked perfectly from a technical perspective, and the message above was not a criticism, I just wanted to know if there was a UX/usability reason for the change in behaviour.