Chasing down non-View Perception tracking warnings?

[tonyarnold]

I notice in the PR for the Swift 6.2 back port (#141) the following note:

Perception checking has been rewritten to be simpler, but you may need to make some changes to avoid warnings. Most notably, you should not be deriving bindings using @State. Instead, use @Perception.Bindable inside of WithPerceptionTracking views to silence any SwiftUI binding access that may happen outside of the view body lifecycle

Does this only apply to @State, or does it affect @Binding as well?

I'm having trouble tracking down a non-View access as the backtrace disappears into AttributeGraph shenanigans that are non-local to my project.

[tonyarnold]

Actually, let's make things easier - here's a tiny sample project that reproduces the issue I am having. I've deliberately made the violation a fatalError to make it more visible.

I can't tell if this situation is a false positive, or if I have a real tracking violation on my hands?

KeyPathery.zip

[stephencelis]

The issue here is nested observable objects. Perception instruments the projection of a @Perception.Bindable object, but you are accessing a property on a nested object. The fix is to localize the @Perception.Bindable to that nested object before handing it off to SwiftUI:

+@Perception.Bindable var stateCache = viewModel.stateCache
 EditorView(
-    name: $viewModel.stateCache["foo", \.name],
-    value: $viewModel.stateCache["foo", \.value]
+    name: $stateCache["foo", \.name],
+    value: $stateCache["foo", \.value]
 )

Nesting objects and having this kind of access is subtle, so if you have ideas to improve the output of the warning message, please let us know!

[tonyarnold]

This was exactly the issue, and the local declaration of the Bindable worked great — thanks!

I believe that my confusion came from the tracking violation message that's printed, specifically:

If a view is using a binding derived from perceptible '@State', \
use '@Perception.Bindable', instead. For example:

In my case, the property on the View was already @Perception.Bindable, not @State, so it wasn't clear that this rule also applied to my situation. It may be worth considering including more detail, or rewording things a bit like:

If a view is using a binding derived from perceptible '@State' or an existing \
'@Perception.Bindable', you will need to declare a '@Perception.Bindable' locally \
within a 'WithPerceptionTracking' closure on your View. For example:

[pyrtsa]

This is an interesting one! What seems to be happening with @Perception.Bindable is that the perception checking machinery only extends to the direct member accesses of Perceptible before you turn them into Bindings.

This seems like a gotcha worth documenting, unless the developer experience could be improved somehow.

When you write:

let nameBinding: Binding<String> = $viewModel.stateCache["foo", \.name]

// equivalently:

let cacheBinding: Binding<StateCache> = $viewModel.stateCache
let nameBinding: Binding<String> = cacheBinding["foo", \.name]

you're actually only accessing $viewModel.stateCache through subscript(dynamicMember:). The subsequent subscript access cacheBinding["foo", \.name] goes through SwiftUI.Binding directly, bypassing the logic that flags isInPerceptionTracking locally.

A workaround that you could use here (although I wish no one had to know about it!) is to call subscript(dynamicMember:) explicitly:

 EditorView(
-    name: $viewModel.stateCache["foo", \.name],
-    value: $viewModel.stateCache["foo", \.value]
+    name: $viewModel[dynamicMember: \.stateCache["foo", \.name]],
+    value: $viewModel[dynamicMember: \.stateCache["foo", \.value]]
 )