[fields] Enable the new field DOM structure by default

[flaviendelangle]

Closes #14477

If possible, this PR should be merged as soon as the next branch is prepared so that I can open the PR to #14796 which also impacts most of the interfaces in the package.

Work

• Enable enableAccessibleFieldDOMStructure when the prop is not provided and render the right text field
• Change the default value of the TEnableAccessibleFieldDOMStructure generic in every component and interface using it
• Stop usign enableAccessibleFieldDOMStructure={true} in doc and tests
• Create the migration guide for v8 and move the guide to migrate to the new DOM structure there
• Update the "Custom field" page to use the new DOM structure by default an only advertise the legacy one for Joy UI
• Use the terminology "Accessible DOM structure" / "Non-accessible DOM structure" everywhere instead of "v6" / "v7" or "legacy"

[mui-bot]

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

Updated pages:

• docs/data/migration/migration-pickers-v7/migration-pickers-v7.md
• docs/data/date-pickers/custom-field/custom-field.md
• docs/data/date-pickers/fields/fields.md
• docs/data/migration/migration-pickers-v6/migration-pickers-v6.md

Generated by 🚫 dangerJS against 0204496

[arthurbalduini]

Maybe we already want to remove the "v6" x "v7" terminology for good ?

It happens on:

• useFieldV7TextField

• useFieldV6TextField

• models/fields.ts

  • BaseForwardedV7SingleInputFieldProps
  • BaseForwardedV6SingleInputFieldProps

• test/utils/pickers/assertions.ts

  • expectFieldValueV7
  • expectFieldValueV6

• internals/hooks/useField/useField.utils.ts

  • createDateStrForV7HiddenInputFromSections
  • createDateStrForV6InputFromSections

• internals/hooks/useField/useField.types.ts

  • UseFieldV7ForwardedProps
  • UseFieldV7AdditionalProps
  • getV7HiddenInputValueFromSections
  • UseFieldV6ForwardedProps
  • UseFieldV6AdditionalProps
  • getV6InputValueFromSections

• test/utils/pickers/fields.tsx

  • skipV7
  • v7Response
  • v6Response

• DateField/tests/editing.DateField.test

  • onChangeV7 (multiple declarations)
  • onChangeV6 (multiple declarations)

• TimeField/tests/editing.TimeField.test.tsx

  • onChangeV7 (multiple declarations)
  • onChangeV6 (multiple declarations)

[arthurbalduini]

Maybe we already want to remove the "v6" x "v7" terminology for good ?

Although I think it can make sense, I also see it as questionable since adding new suffixes could make it more verbose and hardly to read, plus we are already used to the v6 x v7 nomenclature. I wouldn't mind leaving the renaming for v9 once we remove the non-accessible-v6 input

[arthurbalduini]

LGTM 👏
Nice to see so many removed lines, specially in our tests ! 🎉

I'm leaving the approve, I believe the v7xv6 nomenclature doesn't block this PR 🙂

[flaviendelangle]

Thanks for the deep dive on the v6/v7 nomenclature.

Although I think it can make sense, I also see it as questionable since adding new suffixes could make it more verbose and hardly to read, plus we are already used to the v6 x v7 nomenclature. I wouldn't mind leaving the renaming for v9 once we remove the non-accessible-v6 input

I would differenciate public usage of the nomenclature and internal one.
The public usage is "accessible DOM structure", not "v7 DOM structure", so I think any public usage should still follow this nomenclature as muche as possible.
From what I can see, the only public interfaces remaining with v6/v7 is BaseForwardedV6SingleInputFieldProps/BaseForwardedV7SingleInputFieldProps which I can rename but is very rarely used (and is even less useful with the multi input field going away).

All the rest is purely internal, I can rename it for consistency, but as you said everything will go away in v9 so it may not be worth the effort.

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.