[pickers] Add a required prop

[irshadpalayadan]

Duplicates

• I have searched the existing issues

Latest version

• I have tested the latest version

Current behavior 😯

Expected behavior 🤔

Steps to reproduce 🕹

Steps:

Context 🔦

No response

Your environment 🌎

`npx @mui/envinfo`

  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.

[siriwatknp]

Please provide a CodeSandbox so that we can see how you use it, thanks!

[github-actions]

Since the issue is missing key information, and has been inactive for 7 days, it has been automatically closed.
If you wish to see the issue reopened, please provide the missing information.

[henrymcl]

required is not one of the props in <DatePicker/>

That can be passed separately in InputProps and handled in your own renderInput like this:

import { useCallback, useMemo } from 'react';
import { DatePicker } from '@mui/x-date-pickers';
import { TextField } from '@mui/material';

const renderInput = (params) => {
	return <TextField {...params} required={params.InputProps.required} />;
};
const dayOfWeekFormatter = (day) => day.charAt(1);
const views = ['day', 'month', 'year'];

export default ({ value, key, setValue, name, required, label, ...props }) => {
	const callback = useCallback(() => {
		setValue((x) => ({ ...x, [key]: value }));
	}, [setValue, key]);

	const DialogProps = useMemo(() => ({ 'data-name': name }), [name]);
	const InputProps = useMemo(() => ({ required }), [required]);

	return (
		<DatePicker
			inputFormat="YYYY-MM-DD"
			dayOfWeekFormatter={dayOfWeekFormatter}
			value={value}
			onChange={callback}
			renderInput={renderInput}
			DialogProps={DialogProps}
			PopperProps={DialogProps}
			InputProps={InputProps}
			views={views}
			label={label}
			{...props}
		/>
	);
};

Injecting required field of <DatePicker/> to params for renderInput could be really user-friendly though.

[flaviendelangle]

I'm reopening because I do agree we could have a better DX on that one.

[github-actions]

Since the issue is missing key information and has been inactive for 7 days, it has been automatically closed. If you wish to see the issue reopened, please provide the missing information.

[garyb01]

Solution:

[LukasTy]

Given that we support various validation options, I feel that we are sort of missing one of the most important validations—required.
I imagine that many users might often need a required field and some other validation, like disablePast, and given our current API, in order to achieve that visually and functionality it would require a combination of a lot of props and manual validation of required.
Although, it could raise a concern that currently wasn't a problem—when do we trigger the validation state? If we just simply add a required prop to our current validation pipeline, in this case, such a field would always be in an error state and that might often not be the end result that a user wants. 🤔

For this very reason, it does not reasonable to avoid adding such basic validation controls, because more often than not users might be controlling the error state to achieve their desired UX anyways. 🤔

What do you think @flaviendelangle?

[flaviendelangle]

If we just simply add a required prop to our current validation pipeline, in this case, such a field would always be in an error state

Could you elaborate here? I'm not following you.

[LukasTy]

If we just simply add a required prop to our current validation pipeline, in this case, such a field would always be in an error state

Could you elaborate here? I'm not following you.

I meant that if we add a required validation and change the validation to use such a prop, then simply rendering such a component would result in it already being in an error state and that would not be what the end user would like. It could be quite common to use a deferred validation and show the error state only after a certain action (i.e. a submit button click). Thus, our solution could end up being very useful for some people, while only a marginal improvement for others.

In essence, adding this prop does sound useful as there does not seem to be any clear drawbacks. 🤔

[flaviendelangle]

I'm wondering if this prop should be in our validation pipeline, or if it should just pass required={true} to the TextField to use the browser behavior.

This seems more consistent with the rest of the MUI stack BUT it will not work correctly with the v7 multi-HTML-input implementation.

[LukasTy]

I'm not sure we can make the native required input validation work, because we always have a value (format) when a field is focused.
IMHO, if we want to add it, it should reside in our pipeline, otherwise, just close this issue. 🤔
Should we move this task to Needs grooming to discuss it further amongst the whole team?

[flaviendelangle]

Let's discuss it during grooming yes!

[michelengelen]

Was there any decision on this during the grooming @flaviendelangle ?

[LukasTy]

I believe that we decided to introduce the top-level prop and add this validation in a similar manner that we have the other validation props.
The only new "development" is the discovery of how competitors handle it, as mentioned in the 1st point here: #10253 (comment)
It would be really great if we could wire the native required prop validation behavior to our field components, even though they have the value prop when focused. 🤔

[flaviendelangle]

It would be really great if we could wire the native required prop validation behavior to our field components

And have it work with our multi-HTML-input structure of v7 😬

[gitstart]

@LukasTy we would like to pick this up

[LukasTy]

we would like to pick this up

Thank you for expressing the interest. 🙏
Feel free to work on it.
I've assigned the issue to you. 👌

[rishabmahesh]

Is there any progress on this issue?

[LukasTy]

@gitstart Do you have any updates on the progress?
Are you experiencing problems that we could help solve? 🤔
Or should we take over the task if we need it delivered sooner? 👌

[gitstart]

Hi @LukasTy, thanks for checking in.
Unfortunately, due to a lot of internal resource reallocation on our end, we have not been able to make much progress on this issue. Please feel free to reassign the issue if it is urgent, otherwise, we will get back to it as soon as we can.
Apologies for the delay.

[LukasTy]

Please feel free to reassign the issue if it is urgent, otherwise, we will get back to it as soon as we can. Apologies for the delay.

Thank you for the update, no worries. 👌
We'll reassign it if we get enough resources to start work on it as well.

[MiLandry]

Any updates on this?

[LukasTy]

Any updates on this?

Looks like there is no update for now.
We have our hands full with higher-priority issues at the moment. 🙈

Is it a blocker for your use case?
Does manually setting the appropriate props solve your use case? 🤔