Improve performances when rendering days

[gpbl]

@lo1tuma wrote a great comment about rendering performances:

Initially we used modified functions (4 of them) even with memoization. We render 12 months at once. On iOS (mobile safari) and old android devices rendering took serveral seconds (~2 to 5 seconds). Whenever the user interacts with our date range picker, we need the change the modifier functions (=> creating new functions) in order to trigger re-rendering of the DayPicker component, this means those 4 new functions have to be executed again for all 365 days. So every time to user clicks on a day, he has a 2 - 5 second delay until the UI reacts.

This issue is to discuss API changes required to improve the DayPicker rendering performance. All suggestions are welcome :)

[gpbl]

A solution could be @lo1tuma's proposal to let the developer adopt a custom class for rendering days instead of the default one. The default <Day /> component, however, implements some important logic and requiring the user to rewrite it doesn't make much sense.

I'm thinking another approach, something like:

import DayPicker, { Day } from 'react-day-picker';

<DayPicker>
    <Day modifier="selected" from={aDate} to={anotherDate} />
    <Day modifier="disabled" day={disabledDate} />
    <Day modifier="disabled" days={[fooDate, barDate]} /> 
    <Day modifier="veryCustomClass" days={ day=> aVeryCustomLogic(day) } /> 
</DayPicker>

The DayPicker component would parse its children with type Day. If the day cell is in one the specified ranges, it will inherit the modifiers specified in the modifier prop.

At this point i wonder if modifier is still a good name. We could call it className or just type, or even better consider any boolean, not reserved prop as modifier itself:

<Day disabled day={disabledDate} />
<Day selected from={aDate} to={anotherDate} />

[edorivai]

Another thing I've found to significantly impact performance are the moment constructors used to format dates. In my experience formatting the ariaLabel on the <Day /> component impacts performance most when rerendering a calendar, since that requires 28+ calls to the moment constructor. Additionally, rendering the weekdays takes up significant CPU time. I'm guessing the weekdays could be easily optimized using shouldComponentUpdate, or some other form of memoization.

[gpbl]

@edorivai those seem indeed easy tweaks to improve rendering. Would you mind to send a PR?

[gpbl]

The issue with creating new functions at each render is solved with #254 – I think this is a better solution than multiple child Day components (which may help to make the component "more" declarative, tough).

[gpbl]

Published as v5.0.0.

[lo1tuma]

Thank you @gpbl 🍻.