[BUG] settings.range.min and settings.range.max do not inherit manually set date.min and date.max

[whataboutpereira]

date.min seems to have stopped working. The demo site calendar using date.min: 1920-01-01 doesn't go past the default year 1970.

demo link codesandbox link

[ghiscoding]

@whataboutpereira Have you tried with v2.9.7? I've made 2 PRs #253 and #254 that were released in v2.9.7, it slightly modifies the date min/max code, but I'd be really surprised that it would break anything. Anyway, could you try v2.9.7 or even older versions to confirm exactly which release worked and which didn't, so that we can pinpoint which potential PR introduced the regression.

[ghiscoding]

I found the reason of why it doesn't go below 1970 and it's caused by the code below. I think that code has been there for a long time and so the issue must have exists since a long time too.

https://github.com/uvarov-frontend/vanilla-calendar-pro/blob/7c61e39b754a80c8852348947cffc53ab7fa5a18/package/src/scripts/helpers/setVariables.ts#L31-L32

and the reason why the code above is a problem is because the default date is set to 1970-01-01, and so if the user sets the date.min to 1920 then that date is lower than settings.range.min and so the logic says that the condition who wins is the settings.range.min and so the minimum becomes 1970-01-01 (because of default value)... however, if you use instead settings.range.min and set it to 1920-01-01, then it's the inverse and date.min wins because it's 1970-01-01.... so with the logic above 1970-01-01 is always the winner because it's the default value in both cases as shown below!

https://github.com/uvarov-frontend/vanilla-calendar-pro/blob/7c61e39b754a80c8852348947cffc53ab7fa5a18/package/src/scripts/default.ts#L16-L26

@uvarov-frontend considering the issue that I just mentioned above, can the logic be changed?

I did however find an alternative to the issue, if you set both date.min and settings.range.min, then it bypasses the issue because 1970-01-01 is not set anywhere since we overwrote both min dates to use 1920-01-01 which is bypassing the issue as shown below

[whataboutpereira]

Oh well, it seems we've been through this already in https://github.com/uvarov-frontend/vanilla-calendar-pro/issues/183 and I had forgotten about it. It's still very unintuitive. :/

[uvarov-frontend]

I understand that the logic may seem confusing, but the whole essence is described in the documentation. So the code works correctly as intended. https://vanilla-calendar.pro/docs/learn/date-range/start-and-end-of-existing-dates and https://vanilla-calendar.pro/docs/learn/date-range/maximum-and-minimum-date-to-display

[whataboutpereira]

I understand that the logic may seem confusing, but the whole essence is described in the documentation. So the code works correctly as intended. https://vanilla-calendar.pro/docs/learn/date-range/start-and-end-of-existing-dates

Yes, but this example in the docs still doesn't compute. date.min is 1920-01-01, but the calendar doesn't go past 1970 still.

[uvarov-frontend]

I understand that the logic may seem confusing, but the whole essence is described in the documentation. So the code works correctly as intended. https://vanilla-calendar.pro/docs/learn/date-range/start-and-end-of-existing-dates

Yes, but this example in the docs still doesn't compute. date.min is 1920-01-01, but the calendar doesn't go past 1970 still.

Yes, the example in the documentation is not working, I had already forgotten about it.)) This is how it will work correctly:

const options: IOptions = {
  date: {
    min: '1920-01-01',
    max: '2038-12-31',
  },
  settings: {
    range: {
      min: '1920-01-01',
      max: '2038-12-31',
    },
  },
};

Although it should be sufficient to set the date.min and date.max parameters. We'll mark this as a bug and fix it in a future version, thanks for the report.