Within the SwiftUI group, many individuals give you their very own model of a conditional view modifier. It permits you to take a view, and solely apply a view modifier when the situation holds. It usually appears to be like one thing like this:
extension View {
@ViewBuilder
func applyIf<M: View>(situation: Bool, rework: (Self) -> M) -> some View {
if situation {
rework(self)
} else {
self
}
}
}
There are various weblog posts on the market with comparable modifiers. I feel all these weblog posts ought to include an enormous warning signal. Why is the above code problematic? Let us take a look at a pattern.
Within the following code, we’ve got a single state property myState. When it modifications between true and false, we wish to conditionally apply a body:
struct ContentView: View {
@State var myState = false
var physique: some View {
VStack {
Toggle("Toggle", isOn: $myState.animation())
Rectangle()
.applyIf(situation: myState, rework: { $0.body(width: 100) })
}
}
}
Apparently, when working this code, the animation doesn’t look clean in any respect. For those who look intently, you may see that it fades between the “earlier than” and “after” state:
Here is the identical instance, however written with out applyIf:
struct ContentView: View {
@State var myState = false
var physique: some View {
VStack {
Toggle("Toggle", isOn: $myState.animation())
Rectangle()
.body(width: myState ? 100 : nil)
}
}
}
And with the code above, our animation works as anticipated:
Why is the applyIf model damaged? The reply teaches us rather a lot about how SwiftUI works. In UIKit, views are objects, and objects have inherent identification. Which means that two objects are equal if they’re the identical object. UIKit depends on the identification of an object to animate modifications.
In SwiftUI, views are structs — worth sorts — which implies that they do not have identification. For SwiftUI to animate modifications, it wants to match the worth of the view earlier than the animation began and the worth of the view after the animation ends. SwiftUI then interpolates between the 2 values.
To grasp the distinction in habits between the 2 examples, let’s take a look at their sorts. Here is the kind of our Rectangle().applyIf(...):
_ConditionalContent<ModifiedContent<Rectangle, _FrameLayout>, Rectangle>
The outermost kind is a _ConditionalContent. That is an enum that can both include the worth from executing the if department, or the worth from executing the else department. When situation modifications, SwiftUI can not interpolate between the previous and the brand new worth, as they’ve differing kinds. In SwiftUI, when you could have an if/else with a altering situation, a transition occurs: the view from the one department is eliminated and the view for the opposite department is inserted. By default, the transition is a fade, and that is precisely what we’re seeing within the applyIf instance.
In distinction, that is the kind of Rectangle().body(...):
ModifiedContent<Rectangle, _FrameLayout>
After we animate modifications to the body properties, there aren’t any branches for SwiftUI to contemplate. It could simply interpolate between the previous and new worth and all the things works as anticipated.
Within the Rectangle().body(...) instance, we made the view modifier conditional by offering a nil worth for the width. That is one thing that nearly each view modifier assist. For instance, you may add a conditional foreground coloration through the use of an elective coloration, you may add conditional padding through the use of both 0 or a price, and so forth.
Observe that applyIf (or actually, if/else) additionally breaks your animations when you find yourself doing issues appropriately on the “inside”.
Rectangle()
.body(width: myState ? 100 : nil)
.applyIf(situation) { $0.border(Coloration.crimson) }
While you animate situation, the border is not going to animate, and neither will the body. As a result of SwiftUI considers the if/else branches separate views, a (fade) transition will occur as an alternative.
There may be yet one more drawback past animations. While you use applyIf with a view that accommodates a @State property, all state will probably be misplaced when the situation modifications. The reminiscence of @State properties is managed by SwiftUI, based mostly on the place of the view within the view tree. For instance, think about the next view:
struct Stateful: View {
@State var enter: String = ""
var physique: some View {
TextField("My Discipline", textual content: $enter)
}
}
struct Pattern: View {
var flag: Bool
var physique: some View {
Stateful().applyIf(situation: flag) {
$0.background(Coloration.crimson)
}
}
}
After we change flag, the applyIf department modifications, and the Stateful() view has a brand new place (it moved to the opposite department of a _ConditionalContent). This causes the @State property to be reset to its preliminary worth (as a result of so far as SwiftUI is anxious, a brand new view was added to the hierarchy), and the consumer’s textual content is misplaced. The identical drawback additionally occurs with @StateObject.
The difficult half about all of that is that you simply may not see any of those points when constructing your view. Your views look fantastic, however perhaps your animations are a little bit funky, otherwise you typically lose state. Particularly when the situation does not change all that always, you may not even discover.
I might argue that the entire weblog posts that counsel a modifier like applyIf ought to have a giant warning signal. The downsides of applyIf and its variants are under no circumstances apparent, and I’ve sadly seen a bunch of people that have simply copied this into their code bases and had been very pleased with it (till it grew to become a supply of issues weeks later). The truth is, I might argue that no code base ought to have this perform. It simply makes it approach too simple to by chance break animations or state.
For those who’re enthusiastic about understanding how SwiftUI works, you might learn our ebook Considering in SwiftUI, watch our SwiftUI movies on Swift Speak, or attend one in all our workshops.
