Improve touch tap performance

[moonboots]

to: @majapw @lencioni

This PR skips expensive modifier calculations that slow down render performance. These modifiers are computed for every calendar day, which becomes problematic on mobile if we're showing more months.

I instrumented the time spent in each modifier and tested on my Pixel. The total time is ~400ms. 70ms were spent for the today check, and 60ms were spent in the hover checks. I've disabled hover for mobile and added the optional to skip the today check.

The calculateToday prop isn't the cleanest approach, but I think the perf problem is serious enough to address immediately as we work on a more general fix. On this note, I've discussed an approach with Maja of computing these modifiers strictly at the top level instead of lazily at the leaves. This will allow optimizations like only computing today once and only recomputing affected date ranges.

[coveralls]

Coverage remained the same at 87.322% when pulling 76c19cf on moonboots:jack-tap-perf into f1cee85 on airbnb:master.

[ljharb]

ideally boolean props always default to false, such that absence and false are the same - the main exception is when the default is intended to be flipped later in a semver-major bump. If that's not the case here, could this be renamed so that it can default to false?

[moonboots]

@majapw I removed the calculateToday commit (will keep this handy 😉 ) ptal

[majapw]

Let's maybe conditionally send down some of the other modifiers as well, but let's separate out the calculateToday change into a separate PR like we discussed today.

[majapw]

What if we did something similar for the selection related ones?

selected-start requires START_DATE to exist,

selected-end and blocked-minimum-nights require END_DATE,

selected-span and last-in-range require both,

we could apply those conditionals within the touch params as well.

[coveralls]

Coverage remained the same at 87.322% when pulling 1988d19 on moonboots:jack-tap-perf into f1cee85 on airbnb:master.

[coveralls]

Coverage remained the same at 87.322% when pulling fd4890c on moonboots:jack-tap-perf into f1cee85 on airbnb:master.

[majapw]

Looks great to me.

[coveralls]

Coverage remained the same at 87.322% when pulling d2e2320 on moonboots:jack-tap-perf into f1cee85 on airbnb:master.

[palashkaria]

Hey, I came across this part of the code, white trying to make a DayPickerSingleDateController and I'm not sure how ...startDate && { .. } is working.
Can someone explain what they are doing here? startDate is a moment obj, so it throws an error when I try this in console. @moonboots @majapw

[majapw]

Hi @palashkaria, this code doesn't even exist anymore in react-dates but what it was doing was spreading the result of startDate && { ... } onto the object. if startDate is a moment object and therefore truthy, then startDate && { ... } just evaluates to { ... } which is spread onto the parent object. If startDate is falsey, ie null or something similar, then startDate && { ... } resolves to null which does nothing when passed into the spread operator.

Spreading (leading ...) means putting then contents of the object onto the parent. Basically, it's the new Object.assign.

[palashkaria]

Hey, @majapw
I tried this in chrome, and it didn't work, probably not supported by chrome yet in this syntax, hence I got confused

I see that now you do modifiers in CWRP, right? I was probably looking at an old version. Thanks for the quick explaination.