Fix SwiftUI item view onAppear not getting called

[bryankeller]

Details

This fixes onAppear not getting called when SwiftUI item views were reused. The core issue is that, due to views being reused under the hood, updating the rootView of a hosting controller from ReusedHostingController_ofViewType_DayView(3) to ReusedHostingController_ofViewType_DayView(19) would only trigger a content / data update (the text changing from 3 to 19), not an identity update, which is what's really happening here. View reuse is an implementation detail, but it is critical for performance.

To demonstrate the issue, I've made a simple SwiftUI day view that reproduces the problem. Here, we update a a local store in onAppear, and use that value as a text overlay, making it easy to compare that value vs. the expected value. If there's a reuse issue, the numbers don't match, and we make the overlaid text red.

Reuse issue	After fix

private final class Store: ObservableObject {
  @Published var value: Int?
}

struct SwiftUIDayView: View {

  let dayNumber: Int

  @StateObject private var store = Store()

  var body: some View {
    ZStack(alignment: .center) {
      Text("\(dayNumber)")

      if let storeValue = store.value {
        Text("\(storeValue)")
          .foregroundColor((storeValue == dayNumber ? Color.green : Color.red).opacity(0.5))
      }
    }
    .onAppear {
      store.value = dayNumber
    }
  }
}

---

Unfortunately, we need an API change here. The .calendarItemModel extension on SwiftUI.View needs to take in an AnyHashable ID, which we internally use to give the view a stable identifier, even when reused across hosting controllers. For simple cases, one can simply pass a Day or a Month (both of which are Hashable) as the identifier.

IDs are set internally, so this is a non-breaking change.

We might also consider providing an API that looks like this in the future:

CalendarViewRepresentable(...)
  .dayView { dayComponents in
    Text(dayComponents.day)
  }

This closure is a view builder, and leaves the conversion to a CalendarItemModel<SwiftUIWrapperView<SwiftUI.View>> as an implementation detail (which also means we would handle applying IDs to views internally). I haven't fully thought through if this is possible, but it'd be a nice improvement.

Related Issue

#256

Motivation and Context

Bug fix, make SwiftUI integration better

How Has This Been Tested

Example app

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]

@bryn no rush on a review - I'm actually going to revise this a bit to see if I can make this API change purely additive. I think there's a way to manage these IDs internally so that consumers don't need to specify them in their item provider closures.

[bryankeller]

kind of annoying that we need this but we're working with a type-erased AnyCalendarItemModel, so we don't know if the original CalendarItemModel<CalendarItemViewRepresentable> type is a SwiftUIWrapperView or not.

[bryankeller]

unchanged, but I pulled it out of the SwiftUIWrapperView extension since it was private anyways.

[bryankeller]

the magic line that adds a stable ID