[pickers] Add option to reverse displayed years

[thomasmoon]

• [x] I have followed (at least) the PR section of the contributing guide.

Here is a new prop for the date picker which can be used to reverse the list of years and handle the keyboard input appropriately.

With this feature a dedicated year picker can display the years starting from newest to oldest which is especially useful when a wide range of years is supported but the most commonly selected options will be from more recent years.

I could possibly write a new test for this, but currently I experience problems unrelated to this PR with the time adaptors when running tests, e.g.:

AssertionError: expected 'Europe/Helsinki' to equal 'system'
      + expected - actual

      -Europe/Helsinki
      +system
      
      at Context.<anonymous> (packages/x-date-pickers/src/DateCalendar/tests/timezone.DateCalendar.test.tsx:45:54)
      at processImmediate (node:internal/timers:471:21)```

[github-actions[bot]]

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

[mui-bot]

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

Updated pages:

• docs/data/date-pickers/date-calendar/date-calendar.md
• docs/data/date-pickers/date-picker/date-picker.md

Generated by :no_entry_sign: dangerJS against 8e73354e91b4cfa4937ae80cbfd560779986a615

[flaviendelangle]

Hi,

Thanks for your contribution, I will add this PR to our grooming of today to see if that's something we want to support out of the box

[thomasmoon]

Hi,

Thanks for your contribution, I will add this PR to our grooming of today to see if that's something we want to support out of the box

Thanks a lot! All feedback is welcome if I should develop it a bit further. I couldn’t figure out a good way to override the keyboard events without baking it in, but I did refactor those a bit at the same time. Should test the rtl theme still.

I added custom aria translations for the year in my own code when it’s just a year picker. Those could be good to incorporate but new text keys are required and I can only provide English, Finnish and Swedish.

[LukasTy]

Hello @thomasmoon, thank you for your contribution! 🙏 We want to first identify if this is the best solution for a particular problem. Could you share what particular problem you are trying to solve? What kind of data selection you are trying to optimize?

The thing is that we are considering the adoption of MD3 approach to year and month selection and we need to understand if this change will not be a temporary solution that we might end up using soon in the future. 🙈

[thomasmoon]

Hi @LukasTy, the MUI project has been so beneficial, it's great to find a way to contribute.

The case we have, is a watercraft registration, where a range of dates are offered from 1800-2024 (current year) or 1800-2025 (next year).

The possible range is huge, but it's rare that a user would register a boat so old. The most common use case would be in the last few years.

For this reason, it makes sense to start the list from the current year and display the list of years in reverse order (descending vs. ascending).

There is a question of consistency, when days and months are always listed in ascending order, but this option would be used only for a standalone year picker. A screen reader states the year when making selections with the keyboard, so it should be intuitive enough in terms of accessibility. I think this should also be compatible with the MD3 approach if it's possible to limit the views to only the year and hide the day and month selection.

In this case we store the value as an integer and have used a numeric field for the input, so the years can also be stepped using the keyboard when the field is selected. Of course the year can also be typed directly.

Until now, we have used a select with the same list of years in descending order, but replacing it with the same component used for other dates will be an improvement in terms of consistency.

Hopefully this case sheds lights on the need for this feature and happy to hear feedback about the approach.

I'll try to fix the few visual regression tests that failed, not sure if they are related, but this is my first time developing the mui-x project so there is a bit of a learning curve.

Thanks for your consideration on this feature and have a nice weekend!

[flaviendelangle]

For your specific use case where you only have a year to pick, I'm wondering if an autocomplete wouldn't be better. The UX of the year view is not great (I would love to rework it) and when use alone without a day view, I don't see a lot of value compared to a flat list.

[thomasmoon]

For your specific use case where you only have a year to pick, I'm wondering if an autocomplete wouldn't be better. The UX of the year view is not great (I would love to rework it) and when use alone without a day view, I don't see a lot of value compared to a flat list.

The idea was to use the same recognizable element for all date related inputs. 📅

With the keyboard inputs and aria texts baked in, I think it's a good component for year selection. :accessibility:

[flaviendelangle]

OK, consistency in the UI is a very good point here :+1:

[diegovfeder]

Hi there,

This yearsReversed prop/feature you've implement is amazing. It's a perfect fit for my project where recent years are more commonly needed - awesome work!

I'm wondering, is there a timeline for when this might be merged or released? I'd be happy to help move this forward, so if there's anything I can do, please let me know.

Also, if that's not the case, could you share any workarounds to achieve reversed years without altering the base component?

Thanks for your great work on this!

[flaviendelangle]

WDYT @flaviendelangle, do you see any other potential pitfalls?

For me the only problem is the increased API surface which adds a little bit of complexity in the codebase and a little bit of overhead when reading the doc. So we must think that this feature is useful enough to justify those costs (which are small costs)

[LukasTy]

For me the only problem is the increased API surface which adds a little bit of complexity in the codebase and a little bit of overhead when reading the doc. So we must think that this feature is useful enough to justify those costs (which are small costs)

Well, another option is to improve the customization capabilities in the DateCalendar by adding more slots into DateCalendar for each view or changing viewRenderers such that it would be more trivial to change just the relevant portion of view behavior. That is arguably more difficult to do right. Besides, let's look at the yearsPerRow prop, which is probably rarely used. 🙈 😆

[flaviendelangle]

That is arguably more difficult to do right.

Yes, it would probably increase a lot more the complexity of the codebase

Besides, let's look at the yearsPerRow prop, which is probably rarely used.

This one is mostly here to change the value between mobile and destkop in our components, not for users direct usage

[thomasmoon]

Hi guys, thanks again for considering this case and helping to refine it.

I'm definitely willing to help make any needed finalizations and we are still hoping to use the year picker for our case although haven't implemented the forked version yet.

I need to get to know these tests better and push an update and then let's check the situation on how this can be merged.

[LukasTy]

I'm definitely willing to help make any needed finalizations and we are still hoping to use the year picker for our case although haven't implemented the forked version yet.

I'm glad to hear it, thank you. 👌

I need to get to know these tests better and push an update and then let's check the situation on how this can be merged.

Let us know if you need help with writing tests. Our setup isn't the most conventional one. 🤔

[github-actions[bot]]

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