Bk/performance improvements

[bryankeller]

Details

This PR makes 2 performance improvements:

• Prevent a few DateFormatters from getting recreated on every CalendarViewContent creation
• Prevent updateVisibleViews(...) from getting called if the calendar hasn't scrolled far enough for the visible set of views to have changed

Related Issue

N/A

Motivation and Context

Optimizing host calendar in the Airbnb app

How Has This Been Tested

Example app, profiling.

Types of changes

• Docs change / refactoring / dependency upgrade
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My code follows the code style of this project.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.

[bryankeller]

Should be impossible to hit cc @calda

[calda]

What do you mean?

[bryankeller]

@calda I mean the unowned should be "safe" / there's no way to crash here.

[calda]

Perhaps -- although not sure I understand the motivation to change from capturing individual properties (guaranteed to be safe) to using unowned instead (potentially unsafe).

You could feasibly construct a case that crashes by doing something like this:

let content = CalendarViewContent(...)

let monthHeaderItemProvider = content.monthHeaderItemProvider

/// ... later, in a different scope, so content itself has been deallocated

monthBackgroundItemProvider(month) // 💥 crash because content no longer exists but there was an unowned reference to it

so the safety depends on the usage of the content.monthHeaderItemProvider property

[bryankeller]

That would only be possible internally though, since CalendarViewContent doesn't expose its item provider closures publicly.

Capturing the individual properties here causes them to be created immediately (which is expensive for date formatters).

lazy var expensiveProperty = ExpensiveObject()

let foo = { [expensiveProperty] in 
  expensiveProperty.doSomething()
}

// later...
foo()

In this example, expensiveProperty is initialized when foo is initialized, not when foo is called later on.

[calda]

That makes sense -- I guess in a lot of typical usage we'd be initializing the monthHeaderDateFormatter for the defaultMonthHeaderItemProvider but then never even calling the default provider (because the consumer immediately provides a custom provider)

[bryankeller]

we clear this in setContent, since we want updateVisibleViews(...) to run on the next layout pass even if our layout region hasn't changed

[bryankeller]

here's the big optimization - when we're scrolling, we only need to updateVisibleViews(...) if we've scrolled far enough to change our "layout region" (month headers, days, etc. enter / exit the viewport)