mui-x icon indicating copy to clipboard operation
mui-x copied to clipboard

[pickers] onAccept fired even when date is invalid, without information about error

Open pawelproject opened this issue 1 year ago • 2 comments

Steps to reproduce

Link to live example: https://stackblitz.com/edit/react-mnt73n?file=Demo.tsx

Steps:

  1. insert into input date which doesn't pass validation
  2. click calendar icon to open popup/dialog
  3. click outside of calendar or click accept if there is this button

Current behavior

datePickerOnAcceptBug

onAccept is fired, with no information about error

Expected behavior

one of 2 solutions

  1. onAccept is not fired
  2. onAccept is still fired, but with information about context error (something like in onChange)

Context

I am trying to send request to backend whenever user stops entering value and provided value passes validation

Your environment

"react": "18.2.0", "react-dom": "18.2.0", "@mui/x-date-pickers": "6.19.3", "dayjs": "1.11.10", "@emotion/react": "11.11.3", "@emotion/styled": "11.11.0", "@mui/material": "5.15.7", "@types/react": "18.2.55", "@types/react-dom": "18.2.18", "typescript": "5.3.3"
  Firefox 115.4.

Search keywords: pickers, onAccept, validation

pawelproject avatar Feb 07 '24 13:02 pawelproject

Thanks @pawelproject for raising this. IMHO your second proposal sounds good due to the nature of the event. It should be considered as an accept only on the calendar and therefor it is generally correct to fire the event, even with this invalid date.

WDYT @LukasTy ?

michelengelen avatar Feb 07 '24 14:02 michelengelen

@pawelproject thank you for a great observation. 🙏 Comparing the information in the lifecycle docs and the actual behavior in this particular case suggests that we need to fix this behavior or update the documentation. 🙈 IMHO, both suggested approaches seem valid, however, it's probably a bit less error-prone to go with the second option of also including a context in onAccept parameters.

In the meantime, I'd suggest you also listen to the onError callback and fire a backend request only when error === null. What do you think? Would it be a valid compromise? 🤔

LukasTy avatar Feb 07 '24 14:02 LukasTy

:warning: This issue has been closed. If you have a similar problem but not exactly the same, please open a new issue. Now, if you have additional information related to this issue or things that could help future readers, feel free to leave a comment.

@pawelproject: How did we do? Your experience with our support team matters to us. If you have a moment, please share your thoughts in this short Support Satisfaction survey.

github-actions[bot] avatar Jun 19 '24 11:06 github-actions[bot]