Giampaolo Bellavite

Nice work, @rodgobbi! I believe the change is indeed a step forward. However, [this line](https://github.com/rodgobbi/react-day-picker/blob/issue2531/src/selection/useRange.tsx#L48) is where most of the impact occurs. Specifically, it's looping from `newRange.from` to the existing...

PS A suggestion from ChatGPT to improve the loop: > You can improve the performance by moving the expensive differenceInCalendarDays calculation outside of the loop, checking once before entering the...

> Just one important detail, we cannot rely only on the visible `months` returned by the `useCalendar` hook for checking if there is any disabled date within the selected `DateRange`,...

@rodgobbi Cool! I was excited to add the performance tests, and I played around with Lighthouse over the weekend. I’m learning how to set up Lighthouse with GitHub correctly—sorry for...

OK, I had a chance to dig deeper into your PR, @rodgobbi! The performance improvement is noticeable, and it's definitely a step in the right direction. However, the part about...

Looking great, @rodgobbi! Thanks for your effort and patience in addressing my feedback. Your contribution is the first significant one in a while. I’m happy to see this performance bottleneck...

> @gpbl Thanks for the feedback and encouragement! I'm happy to be able to contribute back 🙏 > > As a follow-up, I found a minor bug with the day...

> Removing will hide from developers that the react-day-picker re-exports date-fns/locale for convenience. this is not the first time we get this feedback... but the export has been added in...

@daveallie, thanks for your PR! I see your point. I need to investigate this issue further. I assumed date-fns' `setDefaultOptions` worked per package and it surprised me it "leaked" into...

I really like the idea of a `DateLib` class initialized with options, rather than constantly passing `locale`. However, I'm unsure if we should merge this or undo all your work,...