`DateInput2` behaves wrong with manual entering date value about blueprint HOT 6 OPEN

@Lonli-Lokli that's quite an old version of Blueprint; can you repro the issue with the latest versions of those libraries? It's unlikely that a bug will get fixed in datetime2 v0.x

from blueprint.

@adidahiya Actually it's easy reproduced with new version too, because code is almost the same https://codesandbox.io/p/sandbox/blueprintjs-datetime2-forked-99zpqw?file=%2Fsrc%2FApp.tsx%3A55%2C13

Could you please also provide a workaround for v5? I hope I will port it in my v4 project too.

from blueprint.

@Lonli-Lokli thanks for updating the sandbox. I don't see how you are storing a "previous value" to be restored. As for reporting the value twice, I think you could easily work around that by checking if newDate === dateValue in the change handler?

from blueprint.

@adidahiya Let me first describe my real issue.
Scenario 1
User opens popover by click, then select the date via datepicker - he can select all the allowed values, no issues, we send new date to the API.

Scenario 2
User opens popover by click, then manually starts to enter the date. Here we have a first problem - any date-like value eg '2024' will be handled by date libraries (date-fns or dayjs) as correct, new value will be send to onChange with isUsermodified=true and send to API.
I could workaround this problem with expecting specific length of input

Scenario 3
User opens popover by click, then manually starts to enter the date, entering 2024-01-19. We parse this value as valid and send it to the API. But in order to finish the value (and close the popup) the natural behaviour for web user is to press Enter. Unfortunately, this Enter will second onChange event (while it close the popup)

Scenario 4
User opens popover by click, then manually starts to enter the date, entering 2024-01-19, then pressing Esc (not Enter). this is common for any popovers - you might want to open the control, click & select something but later decide to revert your changes by pressing Esc. Unfortunately it does not happen.

Both Scenario 3 and Scenario 4 could be handled with new event onSubmitted (it should happen with closing popup too). I still hope that if you go with this route you will backport this to v4

So now, answering your question, I do not save anywhere previous value as I dont need them but expecting to get always valid last-submitted from Control.

Re: checking if dates are the same - again, with this approach when onChange is fired on any input it's kind of hard to predict when to revert

from blueprint.

There isn't really a concept of "submitting" in most Blueprint form components. They are very low-level components that have state, and any modification changes that state immediately. This is because they are not meant to be submitted as they are modified. There are some specialized components (like EditableText) that support this UX, but DateInput is not one of them. The expectation for these components is that state is stored, and eventually sent off when the form is submitted.

from blueprint.

Please remember that components might be used outside of any form, so you can name this property as onApplied.

I don't get why you are disagree with the fact that any user input has several states - initial, editing, saved, and each state might be valid and invalid.

from blueprint.