dynamic daterange behaviour for when "from" is set to a date after "to" or the other way round

[cadeyrn]

Hello and thank you for your great datepicker! I would need a bit different behaviour for the daterange if the user selects a start date after the end date or an end date before the starts date.

Let's have a look at the current behaviour:

1. Default: | from: [ 15.08.2023 ] to: [ 22.08.2023 ] |
2. The user changes the "from" field to 28.08.2023 (a date after the current to date)
3. The datepicker does the following: | from: [ 22.08.2023 ] to: [ 28.08.2023 ] |

Instead I expect the following, because the user has explicitly changed the "from" field and not the "to" field:

| from: [ 28.08.2023 ] to: [ 04.09.2023 ] |

Or the other way round, again at first the current behaviour:

1. Default: | from: [ 15.08.2023 ] to: [ 22.08.2023 ] |
2. The user changes the "to" field to 13.08.2023 (a date before the current from date)
3. The datepicker does the following: | from: [ 13.08.2023 ] to: [ 15.08.2023 ] |

Instead I expect the following, because the user has explicitly changed the "to" field and not the "from" field:

| from: [ 06.08.2023 ] to: [ 13.08.2023 ] |

The difference between the dates should be the same as before the change (as long as it's allowed by the min/max dates).

I already tried to solve it by changing the other date in the changeDate event but it didn't work well because that fires changeDate events as well and I can't execute code only for the original change.

Would it be possible to implement something that makes this use case possible? Or are you even aware of a way to do something like this in the current version?

[mymth]

Maybe you can do something like this. https://codepen.io/mymth/pen/xxQvRQr

[cadeyrn]

Thank you very much! I'll try once I am in the office again, but this looks very promising.

[cadeyrn]

I have now integrated your solution and can confirm that this works flawlessly. Thanks again!