[ad_1]
Within the SwiftUI neighborhood, many individuals provide you with their very own model of a conditional view modifier
. It means that you can take a view, and solely apply a view modifier when the situation holds. It usually seems to be one thing like this:
extension View {
@ViewBuilder
func applyIfM: View>(situation: Bool, remodel: (Self) -> M) -> some View {
if situation {
remodel(self)
} else {
self
}
}
}
There are lots of weblog posts on the market with related modifiers. I feel all these weblog posts ought to include an enormous warning signal. Why is the above code problematic? Let’s take a look at a pattern.
Within the following code, we now have a single state property myState
. When it adjustments between true
and false
, we need 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, remodel: { $0.body(width: 100) })
}
}
}
Curiously, when operating this code, the animation doesn’t look easy in any respect. In the event you look carefully, you possibly can see that it fades between the “earlier than” and “after” state:
This 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 id
. Which means that two objects are equal if they’re the identical object. UIKit depends on the id of an object to animate adjustments.
In SwiftUI, views are structs — worth varieties — which implies that they do not have id. For SwiftUI to animate adjustments, 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 conduct between the 2 examples, let’s take a look at their varieties. This 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
comprise the worth from executing the if
department, or
the worth from executing the else
department. When situation adjustments, SwiftUI can not interpolate between the outdated and the brand new worth, as they’ve differing types. In SwiftUI, when you’ve gotten 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>
Once we animate adjustments to the body properties, there are not any branches for SwiftUI to think about. It will probably simply interpolate between the outdated and new worth and all the pieces 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 just about each view modifier assist. For instance, you possibly can add a conditional foreground colour through the use of an optionally available colour, you possibly can add conditional padding through the use of both 0 or a price, and so forth.
Word 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(Shade.purple) }
Once 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 a substitute.
There’s yet one more downside past animations. Once you use applyIf
with a view that comprises a @State
property, all state might be misplaced when the situation adjustments. 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 Subject", textual content: $enter)
}
}
struct Pattern: View {
var flag: Bool
var physique: some View {
Stateful().applyIf(situation: flag) {
$0.background(Shade.purple)
}
}
}
Once we change flag
, the applyIf
department adjustments, 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 worried, a brand new view was added to the hierarchy), and the person’s textual content is misplaced. The identical downside additionally occurs with @StateObject
.
The tough half about all of that is that you simply may not see any of those points when constructing your view. Your views look high-quality, however possibly your animations are a bit funky, otherwise you typically lose state. Particularly when the situation would not change all that always, you may not even discover.
I’d argue that all the weblog posts that recommend a modifier like applyIf
ought to have an enormous warning signal. The downsides of applyIf
and its variants are in no way apparent, and I’ve sadly seen a bunch of people that have simply copied this into their code bases and had been very proud of it (till it grew to become a supply of issues weeks later). In reality, I’d argue that no code base ought to have this perform
. It simply makes it means too straightforward to by chance break animations or state.
In the event you’re curious about understanding how SwiftUI works, you possibly can learn our e book Considering in SwiftUI
, watch our SwiftUI movies
on Swift Discuss, or attend one in every of our workshops
.
[ad_2]