Calendar minDate is mutating input value

[elibolonur]

Bug Report

Hi, I am porting Fomantic Calendar to a Vue component and just noticed a bug. Setting minDate(initially or after initialization) to a date that is later than the input value, it is mutating the input value as well.

Steps to reproduce

1. set minDate to today
2. set the value to a day that is before than minDate (initially)

Expected result

If the initial value is 1 august 2020, and minDate is 1 september 2020, input should show 1 august 2020, not 1 september 2020 which is minDate. It is misleading to show minDate inside input as the input is showing another date than the calendar value holds.

Actual result

Calendar is setting minDate as input value

Testcase

https://codepen.io/onelly/pen/YzqEPKd

Screenshot

Version

2.8.3

[lubber-de]

This is not a bug, but by design. If you provide a minDate, then the calendar component should not allow any value older than the given mindate. But as you provided an older value, this feature just fulfills the requested rule to make sure the current value remains in the defined range, thus sets the value to the minimum possible, which is the minDate.

[digi604]

In our use case we have an existing date and if you want to change it needs to be in the min-max range.... in its current form it does not allow the date to remain the same.

[elibolonur]

I think also minDate and currentValue of the input are 2 different things IMO. Mutating the actual value depending on the minDate does not really make sense. Even though if that is by design fine, but would be nice to have an option to disable it at least as it is also effecting the workflow when you try to port it as a component for a modern JS framework.

[lubber-de]

Personally i would rethink your form logic: If a form value is already out of range, the form should not allow having invalid values given. If your form by design should not allow a date before September 1st, but the value is already set to an older date then at least the form submit/backend logic should complaint about it. For me it sounds like inconsistent logic.

However: What you can do for your usecase is to use the existing callbacks for onShow or onBeforeChange instead of setting the minDate on initialization

onShow

• Do not set a mindate on initialization, but only when the user actively opens the calendar (having the intention to change the date) ...however if the user does not select anything you may also adjust the onHide callback to probably remove the minDate setting again

onBeforeChange

You can think of implementing your minDate logic manually just before the user tries to change the input value and return false in case it does not fit in your desired range

[ko2in]

I think what @digi604 and @elibolonur said is valid and make sense. The minDate shouldn't override the actual input value if it was set. It should only restrict while picking a date in calendar. If the user set the date manually for the input, then it should respect this and leave it as it was.

[lubber-de]

Well, even the set date behavior checks for valid ranges, so a proper PR should take into account that set.date, which can be used manually, is also used internally at several places, especially for range dates (using a start/end calendar) where a boundary restriction of min/maxdate is still needed.

And: What should happen, if one enters a date manually via keyboard without selecting something from the calendar popup? Currently this is also handled to match the min/max boundaries, but should this be removed then as well? i don't think so, because this way somebody could override/trick/ignore any given min/max setting all the time.

[lubber-de]

Somehow related to #1366 where i already provided a new setting autoAdjustDateEdges for #1364.

[elibolonur]

@lubber-de Regarding to your message before; if we assume that a form field "always" will be filled I agree, by design, it makes sense. But if the form field may not be changed but is there as for the presentation, and if the user wants to update the date, then the minimum selectable date should be restricted only, not update the presenting currentValue. That is the scenario, and of course there is a validation layer both in frontend and backend.

And there is another side of it, porting it to vue and keeping all calendar setting properties in sync within vue component lifecycle/state and jQuery state. Suddenly calendar mutates the current value that leads us to an inconsistent vue/fomantic calendar component, which also is an anti pattern. Now, is it possible to accomplish what we are trying to do somehow inside the porting part? For sure yes, with a couple of "hacky" lines of code.

I mean, I understand that it is an issue to disable it and change the workflow. Keeping the current behaviour but giving an option to disable that minDate or maxDate is mutating the currentValue would make it easier, as this is going to be a common case with any modern JS framework where they have their own state management and trying to port fomantic calendar. Or maybe an event like onAutoAdjust to hook to the event or know when it is adjusting to prevent that.

[lubber-de]

@elibolonur Yes, understood 🙂 . I just wanted to point out, that a change has to be done properly and might has more impact than it sounds.