[pickers] Add short weekdays token

[alexfauquette]

Fix master failing

[mui-bot]

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

Generated by 🚫 dangerJS against 3e2c5b9

[flaviendelangle]

Hardcoding the value is not great but I don't have a good idea on how to improve it.
We can make a slightly more specific:

Suggested change

	if (expandedFormat === formatString || formatString === 'ccccc') {
	if (expandedFormat === formatString || (adapter.lib === 'luxon' && formatString === 'ccccc')) {
	// Luxon format 'ccccc' is not supported by the field components since multiple day can have the same one-letter value (e.g: Tuesday and Thursday).
	// It is used in the calendar header to display the day of the weeks.

---

A cleaner approach might be to add entries to the formatTokenMap saying "notSupported` to have a clean error instead of escaping it in Luxon.
But it will improve the bundle size a bit for something not common.

[alexfauquette]

Yes, but in that case we should also think about this behavior for other adapters

[flaviendelangle]

What do you mean by that ?

[alexfauquette]

I was thinking about other adapters that will have the same issue of a token used into the adapter format that's not into the formatTokenMap

The only other example I found is for date-fns: weekdayShort: 'EEEEEE'

For consistency if in luxon we warn that ccccc is not supported, we should do the same with EEEEE for date fns

[flaviendelangle]

But for the other adapters, since we don't escape the token in the adapter (like on Luxon), shouldn't it work already?

[alexfauquette]

Maybe I miss understood your proposal.

For me, you were proposing to add in the formatTokenMap something like ccccc: { sectionType: 'weekDay', contentType: "unsupported token" }

[flaviendelangle]

Something like that yes (not sure about the exact DX).

What I was saying is that for all the adapters except Luxon, the unsupported tokens should have a clean warning thrown by getDateSectionConfigFromFormatToken.
From what I understand, we now escape the non-token words in AdapterLuxon based on the token list we know. So for Luxon, we risk to escape words that are actually token we don't know. But this is not something that can occur on the other adapters.

So maybe just having a string array in AdapterLuxon with the non-supported token would be enough, so that we can avoid to escape them as well, and have getDateSectionConfigFromFormatToken throw the error properly.

Or maybe I'm missing something