View body is called although its #Binding has not changed - ios

Question

SwiftUI promise is to call View’s body only when needed to avoid invalidating views whose State has not changed.
However, there are some cases when this promise is not kept and the View is updated even though its state has not changed.
Example:
struct InsideView: View {
#Binding var value: Int
// …
}
Looking at that view, we’d expect that its body is called when the value changes. However, this is not always true and it depends on how that binding is passed to the view.
When the view is created this way, everything works as expected and InsideView is not updated when value hasn’t changed.
#State private var value: Int = 0
InsideView(value: $value)
In the example below, InsideView will be incorrectly updated even when value has not changed. It will be updated whenever its container is updated too.
var customBinding: Binding<Int> {
Binding<Int> { 100 } set: { _ in }
}
InsideView(value: customBinding)
Can anyone explain this and say whether it's expected? Is there any way to avoid this behaviour that can ultimately lead to performance issues?
Here's a sample project if anyone wants to play with it.
And here's a full code if you just want to paste it to your project:
import SwiftUI
struct ContentView: View {
#State private var tab = 0
#State private var count = 0
#State private var someValue: Int = 100
var customBinding: Binding<Int> {
Binding<Int> { 100 } set: { _ in }
}
var body: some View {
VStack {
Picker("Tab", selection: $tab) {
Text("#Binding from #State").tag(0)
Text("Custom #Binding").tag(1)
}
.pickerStyle(SegmentedPickerStyle())
VStack(spacing: 10) {
if tab == 0 {
Text("When you tap a button, a view below should not be updated. That's a desired behaviour.")
InsideView(value: $someValue)
} else if tab == 1 {
Text("When you tap a button, a view below will be updated (its background color will be set to random value to indicate this). This is unexpected because the view State has not changed.")
InsideView(value: customBinding)
}
}
.frame(width: 250, height: 150)
Button("Tap! Count: \(count)") {
count += 1
}
}
.frame(width: 300, height: 350)
.padding()
}
}
struct InsideView: View {
#Binding var value: Int
var body: some View {
print("[⚠️] InsideView body.")
return VStack {
Text("I'm a child view. My body should be called only once.")
.multilineTextAlignment(.center)
Text("Value: \(value)")
}
.background(Color.random)
}
}
extension ShapeStyle where Self == Color {
static var random: Color {
Color(
red: .random(in: 0...1),
green: .random(in: 0...1),
blue: .random(in: 0...1)
)
}
}

Answer 1

Hmm i think the reason is being updated is because you are using a computed property in the ContentView view. and even if it's not tagged with a state annotation like #State, #Binding,#Stateobject... its a view state regardless, and swiftui use that to infer the difference between a view with an old state and a new state. And you're getting a new binding object at every contentview body update.
you can try change the init from what you have to something like this
let customBinding: Binding<Int>
init() {
self.customBinding = Binding<Int> { 99 } set: { _ in }
}
but i would advise against this approach because simply is not useful to create a binding like this in the view, because you can't change anything inside the set because it's the init of a struct.
Instead you can pass in the init an ObservableObject where you moved the state logic to an ObservableObject and use that.
something like this
class ContentViewState: ObservableObject {
#Published var someValue: Int = 100
var customBinding: Binding<Int> = .constant(0)
init() {
customBinding = Binding<Int> { [weak self] in
self?.someValue ?? 0
}
set: { [weak self] in
self?.someValue = $0
}
}
}
// and change the InsideView like
struct InsideView: View {
#ObservedObject private var state: ContentViewState
#Binding var value: Int
init(state: ContentViewState) {
self.state = state
_value = state.customBinding
}
...
}
I would still use the $ with simple #state notation most of the time where i don't have complicated states to handle, but this can be another approach i guess.