[fields] Always use props.value as the source of truth when defined
#15875
Conversation
flaviendelangle
added
bug 🐛
|
Deploy preview: https://deploy-preview-15875--material-ui-x.netlify.app/ |
flaviendelangle
changed the title
props.value as the source of truth when defined
flaviendelangle
force-pushed
the
value-field-source-of-truth
branch
from
169db6a to
4c89824
Compare
flaviendelangle
force-pushed
the
value-field-source-of-truth
branch
from
4c89824 to
4a2952e
Compare
…o value-field-source-of-truth
| // For Day.js: "[Escaped] YYYY" | ||
| format: `${startChar}Escaped${endChar} ${adapter.formats.year}`, | ||
| enableAccessibleFieldDOMStructure: false, | ||
| value: null, |
There was a problem hiding this comment.
I fixed a lot of tests that were switching from uncontrolled to controlled.
| * Object used to access and update the active date (i.e: the date containing the active section). | ||
| * Mainly useful in the range fields where we need to update the date containing the active section without impacting the other one. | ||
| */ | ||
| interface FieldActiveDateManager<TValue extends PickerValidValue> { |
There was a problem hiding this comment.
I'm removing this concept because we don't need to update the reference value in multiple places anymore.
Instead I aligned the needed methods inside the field value manager.
| /** | ||
| * Last value of the parameters used to generate the sections. | ||
| */ | ||
| lastSectionsDependencies: { format: string; isRtl: boolean; locale: any }; |
There was a problem hiding this comment.
I'm storing those in state instead of using an effect to avoid a double re-render.
It's not strictly related to this PR but since I moved to this approach for the value update, I feared mis-synchronization if one update was in the render and another was in an effect.
| @@ -659,12 +659,15 @@ const transferDateSectionValue = ( | |||
| } | |||
|
|
|||
| case 'weekDay': { | |||
| let dayInWeekStrOfActiveDate = utils.formatByString(dateToTransferFrom, section.format); | |||
There was a problem hiding this comment.
This fixes a bug highlighted by the new behavior but already here before.
For the E format of Luxon, the day of the week does not have leading zeroes, so dayInWeekStrOfActiveDate was equal to let's say 4and formattedDaysInWeek was ['1', '2, ...].
Which means dayInWeekOfNewSectionValue was equal to -1 and that messed up with the editing.
Before the bug was only visible on the value passed to onChange.
Now it's also visible on the value rendered.
So this PR also improves how we actually test all the tokens 👌
| @@ -191,8 +191,10 @@ export interface MuiPickersAdapter<TLocale = any> { | |||
| value?: T, | |||
| timezone?: PickersTimezone, | |||
| ): DateBuilderReturnType<T>; | |||
| // TODO v9: Remove. | |||
There was a problem hiding this comment.
We don't need it anymore, but it does not cost much to keep it so I'm deprecating it for next major.
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
props.valueas the source of truth inusePickerValue(should be a lot simpler)