mui / mui-x

MUI X: Build complex and data-rich applications using a growing list of advanced React components, like the Data Grid, Date and Time Pickers, Charts, and more!
https://mui.com/x/
4.16k stars 1.3k forks source link

[pickers] DateTime.fromISO() is not handling null values #10192

Closed Arkamit closed 1 year ago

Arkamit commented 1 year ago

Duplicates

Latest version

Steps to reproduce 🕹

Link to live example: https://codesandbox.io/s/restless-shadow-q37dg4?file=/Demo.tsx

Current behavior 😯

If we initialize the Date Picker with null values, the DateTime.fromISO() method throws an invalidDate error.

Expected behavior 🤔

the DateTime.fromISO() method should be able to handle null values for initializing the component with empty values.

Context 🔦

I'm trying to initialize the date picker component with empty value.

Your environment 🌎

npx @mui/envinfo ``` Browser: Google Chrome System: OS: Linux 4.14 Amazon Linux 2 CPU: (4) x64 AMD EPYC 7571 Memory: 12.07 GB / 15.52 GB Container: Yes Shell: 4.2.46 - /bin/bash Binaries: Node: 16.14.2 - /usr/local/bin/node npm: 8.5.0 - /usr/local/bin/npm Managers: pip2: 18.0 - /usr/bin/pip2 pip3: 20.2.2 - /usr/bin/pip3 Yum: 3.4.3 - /usr/bin/yum Utilities: Make: 3.82 - /usr/bin/make Git: 2.32.0 - /usr/bin/git Virtualization: Docker: 20.10.13 - /usr/bin/docker IDEs: Nano: 2.9.8 - /usr/bin/nano VSCode: 1.81.1 - /home/adutta@huronconsultinggroup.com/.vscode-server/bin/6c3e3dba23e8fadc360aed75ce363ba185c49794/bin/remote-cli/code Vim: 8.2 - /usr/bin/vim Languages: Bash: 4.2.46 - /usr/bin/bash Perl: 5.16.3 - /usr/bin/perl Python: 2.7.18 - /usr/bin/python Python3: 3.7.10 - /usr/bin/python3 Databases: SQLite: 3.7.17 - /usr/bin/sqlite3 ```

Order ID or Support key 💳 (optional)

59954

flaviendelangle commented 1 year ago

What you are describing is the behavior from Luxon. DateTime.fromISO(value) returns an invalid date, so when you pass it to the picker, we display an error.

I would advise you to always store a Luxon object in state, not an ISO string. Because right now, you are storing an ISO string, parsing it with fromISO and then storing a Luxon object, that will be parsed with DateTime.fromISO, this works but it's super weird and goes against Luxon types.


Or if you really need an ISO string, they check if it is null and if so pass null to the picker

const parsedValue = React.useMemo(() => value == null ? value : DateTime.fromISO(value), [value])

In which case you need to stringify it back in your change handler to actually store a string.

Arkamit commented 1 year ago

@flaviendelangle Thanks for your suggestion. Adding a null check does work. I was just confused with the fact that when we add some month or day and then remove everything, the value becomes null again but this time it doesn't throw the error and reason comes as null instead of invalidDate which is a bit weird. Unfortunately I couldn't find any examples of initializing a datepicker with null or empty values for luxon adapter as well.

flaviendelangle commented 1 year ago

Unfortunately I couldn't find any examples of initializing a datepicker with null or empty values for luxon adapter as well.

These behaviors are not specific to Luxon. For any adapter, null is the value when no date is selected, whereas the invalid date (in the format of your date library) represents an invalid date.

If you are still doing fromISO even with the null check, could you tell me why you are not storing the parsed object in state instead of parsing it during the render ?


when we add some month or day and then remove everything, the value becomes null again but this time it doesn't throw the error and reason comes as null instead of invalidDate which is a bit weird.

I did not understand that part, could you please describe more in depth? When you remove all the sections, the value is null so we fire onChange with null not with an invalid date. Our components almost never fires an invalid date, the only reason I can see is if you type something like 31 April.

Arkamit commented 1 year ago

When you remove all the sections, the value is null so we fire onChange with null not with an invalid date. Our components almost never fires an invalid date, the only reason I can see is if you type something like 31 April.

This answers my question. I'm now using the null check for the initialization. Thanks for your help.