Planning v9

[gpbl]

v9 will improve accessibility, internationalization, performance and typings. For each of these areas, there are breaking changes that requires to bump the major version.

Others may use this thread to discuss each of those. This post will be updated.

---

Accessibility

DayPicker renders an HTMLTable that causes extra complications for accessibility:

• a11y: fix wrong role for day button #1708
• Bug: gridcell ARIA role incorrectly added to Day button element #1688
• Not seeing aria labels on day buttons #1545
• Ability to override the table element when the RowComponent is not returning `tr` element #1539
• Working with day button identifiers following recent accessibility changes #1716

We need to change the rendered HTML to adopt the latest accessibility standard about date pickers.

• Remove table and use div elements only (use ARIA-attributes and CSS display).
• Fix tab order for next/previous button on RTL: #1756

Internationalization

• Add support for Jalali calendar: #1825

To fix this, we would probably make DayPicker able to switch date library, which is a feature we dream since #1087.

Performance

• Fix performance issues: Too slow with higher numberOfMonths #1473

This will probably require to refactor some internals and the hooks.

Typings

• Use generic constraints: #1583
• Allow stricter TypeScript: #1769

Others

• Add a ref with focus method: #1735

In consideration

• Allow switch to other date libraries: #1087
• Animation when changing months: #87

[GeorgeTaveras1231]

@gpbl re: the point "Allow switch to other date libraries", have you considered allowing it to work with the Temporal.PlainDate object? It's at Stage 3 at the moment so it may be good to begin playing with it to possibly adopt. One downside is many developers may have to use polyfills for some time, but would be nice once the polyfills can be removed.

I hope at least that if you consider implementing the ability to work with many date libraries, you consider making the API work with different date objects (other than the [Now Legacy] Date object).

https://tc39.es/proposal-temporal/docs/plaindate.html

[gpbl]

I'd love to give a try to Temporal.PlainDate! Here is the polyfill: https://www.npmjs.com/package/@js-temporal/polyfill

[dimitur2204]

@gpbl I have been using the library somewhat extensively at work and could help out with some things in the future. Would love to play with the new Temporal.

[gpbl]

Hi @dimitur2204, your experience would be useful for sure - thanks!

I should say that relying on polyfills could be hard. Time ago, I tried to use Intl for localization when a polyfill was still required, and I had to give up: these kind of new API should be supported server-side too.

Anyway, it is indeed worth investigate how to replace date-fns with the Temporal API.

If you want to get started, please get familiar with the next major version in the branch https://github.com/gpbl/react-day-picker/tree/next.

There, you can search for the functions imported by date-fns, and see how to replace them. Typings, and that Locale object, may be difficult.

The goal could be switch to the different date library, e.g. using a dateLib prop:

// Render DayPicker using `Temporal` API
import { differenceInCalendarDays } from './temporal-date-lib'; // the module we are missing
<DayPicker dateLib={{ differenceInCalendarDays }} />

// Render using `date-fns`
import { differenceInCalendarDays } from 'date-fns';
<DayPicker dateLib={{ differenceInCalendarDays }} />

I'd suggest to start with some basic util, such as differenceInCalendarDays.

Please let us know if you make some progress or how we can help you...

[dimitur2204]

Thanks for the info. I will get into it and try to get an undertstanding of the repo. I will keep these things in mind.