[fields] Always use props.value as the source of truth when defined

[flaviendelangle]

Part of #15530

We should now have a behavior coherent with the browser input and working well on range inputs as well.
Not sure if we should count that purely as a bug fix or as a breaking change.

Follow up

• Always use the props.value as the source of truth in usePickerValue (should be a lot simpler)

[mui-bot]

Deploy preview: https://deploy-preview-15875--material-ui-x.netlify.app/

Updated pages:

• docs/data/migration/migration-pickers-v7/migration-pickers-v7.md

Generated by 🚫 dangerJS against 6121b7b

[flaviendelangle]

As you said, the only value I see in the invalid date is for people that want to differentiate an empty date and a partially filled date.
If we have feedbacks going in this direction, we could pass a simplified version of the state.sections object in the onChange callback (or some other more direct information to say "it's partially filled"). Using the invalid date to detect this feels like relying on an implementation detail to me so migrating away from it will improve people's code eventually.

[LukasTy]

If we have feedbacks going in this direction, we could pass a simplified version of the state.sections object in the onChange callback (or some other more direct information to say "it's partially filled"). Using the invalid date to detect this feels like relying on an implementation detail to me so migrating away from it will improve people's code eventually.

Yes, thoroughly re-checking the code and thinking about it more, I've come to a similar conclusion. 👌
Let's go with simplification and once we have clear user needs - we can improve the existing solution to cater to this intermediate state. 👍
WDYT?

[flaviendelangle]

WDYT?
I'm all in favor of going that way 👌

[flaviendelangle]

@LukasTy the PR is updated and the test are passing 🙏

[LukasTy]

Looks great, but I think we could still have one "undefined" case:

• enter any valid value
• copy year section value
• move to month or day section and paste the copied value

Currently this would trigger an error state with invalidDate validation.
On this PR we no longer have the error state and the onError callback returns null null as if there is no value and no error, but the field keeps the invalid section values. 🙈

Screen.Recording.2025-03-04.at.10.30.16.mov

This leads me to another question - what about the invalidDate validation?
Does/would it still make sense after this change? 🤔

[flaviendelangle]

This leads me to another question - what about the invalidDate validation?

People can still be invalid date from the outside.
I do agree it's not super frequent, but I think the validation should still support it

---

I'll check the regression you're describing 👍

[flaviendelangle]

@LukasTy I did not handle fully-filled but invalid dates correctly.
For me we have two ways of handling it:

1. We refuse the update (the section does not update)
2. We fire an invalid date

Note: the browser input does not support copy pasting at all from what I can see, so we can't take inspiration there.
Imo, firing an invalid date is the best solution here.

[LukasTy]

I did not handle fully-filled but invalid dates correctly. For me we have two ways of handling it:

1. We refuse the update (the section does not update)
2. We fire an invalid date

Note: the browser input does not support copy pasting at all from what I can see, so we can't take inspiration there. Imo, firing an invalid date is the best solution here.

I think that your chosen behavior makes a lot of sense. 👍
That's also what we do currently, so, it will minimize the amount of breaking behaviors. 🙌

Could we add a migration page entry and a changelog in the PR comment? 🤔

[flaviendelangle]

@LukasTy I added a small migration guide 👍