Closed Arkamit closed 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.
@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.
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
.
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.
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 🌎
``` 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 ```npx @mui/envinfo
Order ID or Support key 💳 (optional)
59954