How can we bridge escaping callbacks from external systems with non-Sendable ViewStore's?

[jpsim]

Given that ViewStore is not thread-safe and not Sendable by design (see docs), how would you suggest we handle long-living escaping callbacks from views that we do not control or do not want to TCA-ify for whatever reason?

This becomes pretty quickly apparent on a large codebase with SWIFT_STRICT_CONCURRENCY=complete where the following becomes a warning:

var body: some View {
  WithViewStore(store, observe: { $0 }) { viewStore in
    SomeExternalView(escapingCallback: {
      viewStore.send(.someAction) // <- capture of 'viewStore' with non-Sendable type ViewStore<..., ...>
    })
  }
}

Which is possible to work around in an unchecked (and likely unsafe) way with UncheckedSendable:

var body: some View {
  WithViewStore(store, observe: { $0 }) { viewStore in
    let uncheckedViewStore = UncheckedSendable(viewStore)
    SomeExternalView(escapingCallback: {
      uncheckedViewStore.value.send(.someAction) // <- no warning
    })
  }
}

[stephencelis]

@jpsim What does SomeExternalView look like? Is its escaping closure sendable?

We have concurrency warnings cranked to the max in many of our demos, including TicTacToe, which calls ViewStore.send in an escaping button action closure here with no warnings:

swift-composable-architecture/Examples/TicTacToe/tic-tac-toe/Sources/GameSwiftUI/GameView.swift

Lines 81 to 83 in 9bc00c5

	Button {
	viewStore.send(.cellTapped(row: row, column: column))
	} label: {

If SomeExternalView is using a sendable closure, then making your ViewStore unchecked-sendable is currently the way to go until we get the view store isolated to the main actor. And if the closure can be called on a non-main thread you'll also need to dispatch the call to ViewStore.send to the main queue.

[jpsim]

Nevermind, I misunderstood the issue here, I just needed to annotate some closures as @MainActor and it's fine now.