{"id":9740,"date":"2023-02-27T13:05:00","date_gmt":"2023-02-27T10:05:00","guid":{"rendered":"https:\/\/handoli.com\/index.php\/2023\/02\/27\/swiftui-views-versus-modifiers\/"},"modified":"2023-02-27T13:05:00","modified_gmt":"2023-02-27T10:05:00","slug":"swiftui-views-versus-modifiers","status":"publish","type":"post","link":"https:\/\/handoli.com\/index.php\/2023\/02\/27\/swiftui-views-versus-modifiers\/","title":{"rendered":"SwiftUI views versus modifiers"},"content":{"rendered":"

One of the most interesting aspects of SwiftUI, at least from an architectural perspective, is how it essentially treats views as data. After all, a SwiftUI view isn\u2019t a direct representation of the pixels that are being rendered on the screen, but rather a description<\/em> of how a given piece of UI should work, look, and behave.<\/p>\n

That very data-driven approach gives us a ton of flexibility when it comes to how we structure our view code \u2014 to the point where one might even start to question what the difference actually is between defining a piece of UI as a view type, versus implementing that same code as a modifier instead.<\/p>\n

Take the following FeaturedLabel<\/code> view as an example \u2014 it adds a leading star image to a given text, and also applies a specific foreground color and font to make that text stand out as being \u201cfeatured\u201d:<\/p>\n

struct<\/span> FeaturedLabel: View<\/span> {\n    var<\/span> text: String<\/span>\n\n    var<\/span> body: some<\/span> View<\/span> {\n        HStack<\/span> {\n            Image<\/span>(systemName: \"star\"<\/span>)\n            Text<\/span>(text)\n        }\n        .foregroundColor<\/span>(.orange<\/span>)\n        .font<\/span>(.headline<\/span>)\n    }\n}<\/code><\/pre>\n
While the above may look like a typical custom view, the exact same rendered UI could just as easily be achieved using a \u201cmodifier-like\u201d View<\/code> protocol extension instead \u2014 like this:<\/p>\n
extension<\/span> View<\/span> {\n    func<\/span> featured() -> some<\/span> View<\/span> {\n        HStack<\/span> {\n            Image<\/span>(systemName: \"star\"<\/span>)\n            self<\/span>\n        }\n        .foregroundColor<\/span>(.orange<\/span>)\n        .font<\/span>(.headline<\/span>)\n    }\n}<\/code><\/pre>\n
Here\u2019s what those two different solutions look like side-by-side when placed within an example ContentView<\/code>:<\/p>\n
struct<\/span> ContentView: View<\/span> {\n    var<\/span> body: some<\/span> View<\/span> {\n        VStack<\/span> {\n            \/\/ View-based version:<\/span>\n            FeaturedLabel<\/span>(text: \"Hello, world!\"<\/span>)\n\n            \/\/ Modifier-based version:<\/span>\n            Text<\/span>(\"Hello, world!\"<\/span>).featured<\/span>()\n        }\n    }\n}<\/code><\/pre>\n
One key difference between our two solutions, though, is that the latter can be applied to any view<\/em>, while the former only enables us to create String<\/code>-based featured labels. That\u2019s something that we could address, though, by turning our FeaturedLabel<\/code> into a custom container view that accepts any kind of View<\/code>-conforming content, rather than just a plain string:<\/p>\n
struct<\/span> FeaturedLabel<Content: View<\/span>>: View<\/span> {\n    @ViewBuilder var<\/span> content: () -> Content<\/span>\n\n    var<\/span> body: some<\/span> View<\/span> {\n        HStack<\/span> {\n            Image<\/span>(systemName: \"star\"<\/span>)\n            content<\/span>()\n        }\n        .foregroundColor<\/span>(.orange<\/span>)\n        .font<\/span>(.headline<\/span>)\n    }\n}<\/code><\/pre>\n
Above we\u2019re adding the ViewBuilder<\/code> attribute to our content<\/code> closure in order to enable the full power of SwiftUI\u2019s view building API to be used at each call site (which, for example, lets us use if<\/code> and switch<\/code> statements when building the content for each FeaturedLabel<\/code>).<\/p>\n
We might still want to make it easy to initialize a FeaturedLabel<\/code> instance with a string, though, rather than always having to pass a closure containing a Text<\/code> view. Thankfully, that\u2019s something that we can easily make possible using a type-constrained extension:<\/p>\n
extension<\/span> FeaturedLabel<\/span> where<\/span> Content<\/span> == Text<\/span> {\n    init<\/span>(_<\/span> text: String<\/span>) {\n        self<\/span>.init<\/span> {\n            Text<\/span>(text)\n        }\n    }\n}<\/code><\/pre>\n
Above we\u2019re using an underscore to remove the external parameter label for text<\/code>, to mimic the way SwiftUI\u2019s own, built-in convenience APIs work for types like Button<\/code> and NavigationLink<\/code>.<\/p>\n
With those changes in place, both of our two solutions now have the exact same amount of flexibility, and can easily be used to create both text-based labels, as well as labels that render any kind of SwiftUI view that we want:<\/p>\n
struct<\/span> ContentView: View<\/span> {\n    @State private var<\/span> isToggleOn = false\n\n    var<\/span> body: some<\/span> View<\/span> {\n        VStack<\/span> {\n            \/\/ Using texts:<\/span>\n            Group<\/span> {\n                \/\/ View-based version:<\/span>\n                FeaturedLabel<\/span>(\"Hello, world!\"<\/span>)\n\n                \/\/ Modifier-based version:<\/span>\n                Text<\/span>(\"Hello, world!\"<\/span>).featured<\/span>()\n            }\n\n            \/\/ Using toggles:<\/span>\n            Group<\/span> {\n                \/\/ View-based version:<\/span>\n                FeaturedLabel<\/span> {\n                    Toggle<\/span>(\"Toggle\"<\/span>, isOn: $isToggleOn<\/span>)\n                }\n\n                \/\/ Modifier-based version:<\/span>\n                Toggle<\/span>(\"Toggle\"<\/span>, isOn: $isToggleOn<\/span>).featured<\/span>()\n            }\n        }\n    }\n}<\/code><\/pre>\n
So at this point, we might really<\/em> start to ask ourselves \u2014 what exactly is the difference between defining a piece of UI as a view versus a modifier? Is there really any practical differences at all, besides code style and structure?<\/p>\n
Well, what about state? Let\u2019s say that we wanted to make our new featured labels automatically fade in when they first appear? That would require us to define something like a @State<\/code>-marked opacity<\/code> property that we\u2019d then animate over using an onAppear<\/code> closure \u2014 for example like this:<\/p>\n
struct<\/span> FeaturedLabel<Content: View<\/span>>: View<\/span> {\n    @ViewBuilder var<\/span> content: () -> Content<\/span>\n    @State private var<\/span> opacity = 0.0<\/span>\n\n    var<\/span> body: some<\/span> View<\/span> {\n        HStack<\/span> {\n            Image<\/span>(systemName: \"star\"<\/span>)\n            content<\/span>()\n        }\n        .foregroundColor<\/span>(.orange<\/span>)\n        .font<\/span>(.headline<\/span>)\n        .opacity<\/span>(opacity)\n        .onAppear<\/span> {\n            withAnimation<\/span> {\n                opacity = 1<\/span>\n            }\n        }\n    }\n}<\/code><\/pre>\n
At first, participating in the SwiftUI state management system might seem like something that only proper view types can do, but it turns out that modifiers have the exact same capability \u2014 as long as we define such a modifier as a proper ViewModifier<\/code>-conforming type, rather than just using a View<\/code> protocol extension:<\/p>\n
struct<\/span> FeaturedModifier: ViewModifier<\/span> {\n    @State private var<\/span> opacity = 0.0<\/span>\n\n    func<\/span> body(content: Content<\/span>) -> some<\/span> View<\/span> {\n        HStack<\/span> {\n            Image<\/span>(systemName: \"star\"<\/span>)\n            content\n        }\n        .foregroundColor<\/span>(.orange<\/span>)\n        .font<\/span>(.headline<\/span>)\n        .opacity<\/span>(opacity)\n        .onAppear<\/span> {\n            withAnimation<\/span> {\n                opacity = 1<\/span>\n            }\n        }\n    }\n}<\/code><\/pre>\n
With the above in place, we can now replace our previous featured<\/code> method implementation with a call to add our new FeaturedModifier<\/code> to the current view \u2014 and both of our two featured label approaches will once again have the exact same end result:<\/p>\n
extension<\/span> View<\/span> {\n    func<\/span> featured() -> some<\/span> View<\/span> {\n        modifier<\/span>(FeaturedModifier<\/span>())\n    }\n}<\/code><\/pre>\n
Also worth noting is that when wrapping our code within a ViewModifier<\/code> type, that code is lazily evaluated when needed, rather than being executed up-front when the modifier is first added, which could make a difference performance-wise in certain situations.<\/p>\n
So, regardless of whether we want to change the styles or structure of a view, or introduce a new piece of state, it\u2019s starting to become clear that SwiftUI views and modifiers have the exact same capabilities. But that brings us to the next question \u2014 if there are no practical differences between the two approaches, how do we choose between them?<\/p>\n
At least to me, it all comes down to the structure<\/em> of the resulting view hierarchy. Although we were, technically, changing the view hierarchy when wrapping one of our featured labels within an HStack<\/code> in order to add our star image, conceptually, that was more about styling<\/em> than it was about structure. When applying the featured<\/code> modifier to a view, its layout or placement within the view hierarchy didn\u2019t really change in any meaningful way \u2014 it still just remained a single view with the exact same kind of overall layout, at least from a high-level perspective.<\/p>\n
That\u2019s not always the case, though. So let\u2019s take a look at another example which should illustrate the potential structural differences between views and modifiers a bit more clearly.<\/p>\n
Here we\u2019ve written a SplitView<\/code> container, which takes two views \u2014 one leading, and one trailing \u2014 and then renders them side-by-side with a divider between them, while also maximizing their frames so that they\u2019ll end up splitting the available space equally:<\/p>\n
struct<\/span> SplitView<Leading: View<\/span>, Trailing: View<\/span>>: View<\/span> {\n    @ViewBuilder var<\/span> leading: () -> Leading<\/span>\n    @ViewBuilder var<\/span> trailing: () -> Trailing<\/span>\n\n    var<\/span> body: some<\/span> View<\/span> {\n        HStack<\/span> {\n            prepareSubview<\/span>(leading<\/span>())\n            Divider<\/span>()\n            prepareSubview<\/span>(trailing<\/span>())\n        }\n    }\n\n    private func<\/span> prepareSubview(_<\/span> view: some<\/span> View<\/span>) -> some<\/span> View<\/span> {\n        view.frame<\/span>(maxWidth: .infinity<\/span>, maxHeight: .infinity<\/span>)\n    }\n}<\/code><\/pre>\n
Just like before, we could definitely achieve the exact same result using a modifier-based approach instead \u2014 which could look like this:<\/p>\n
extension<\/span> View<\/span> {\n    func<\/span> split(with trailingView: some<\/span> View<\/span>) -> some<\/span> View<\/span> {\n        HStack<\/span> {\n            maximize<\/span>()\n            Divider<\/span>()\n            trailingView.maximize<\/span>()\n        }\n    }\n\n    func<\/span> maximize() -> some<\/span> View<\/span> {\n        frame<\/span>(maxWidth: .infinity<\/span>, maxHeight: .infinity<\/span>)\n    }\n}<\/code><\/pre>\n
However, if we once again put our two solutions next to each other within the same example ContentView<\/code>, then we can start to see that this time the two approaches do look quite different in terms of structure and clarity:<\/p>\n
struct<\/span> ContentView: View<\/span> {\n    var<\/span> body: some<\/span> View<\/span> {\n        VStack<\/span> {\n            \/\/ View-based version:<\/span>\n            SplitView<\/span>(leading: {\n                Text<\/span>(\"Leading\"<\/span>)\n            }, trailing: {\n                Text<\/span>(\"Trailing\"<\/span>)\n            })\n\n            \/\/ Modifier-based version:<\/span>\n            Text<\/span>(\"Leading\"<\/span>).split<\/span>(with: Text<\/span>(\"Trailing\"<\/span>))\n        }\n    }\n}<\/code><\/pre>\n
Looking at the view-based call site above, it\u2019s very clear that our two texts are being wrapped within a container, and it\u2019s also easy to tell which of those two texts will end up being the leading versus trailing view.<\/p>\n
That same thing can\u2019t really be said for the modifier-based version this time, though, which really requires us to know that the view that we\u2019re applying<\/em> the modifier to will end up in the leading slot. Plus, we can\u2019t really tell that those two texts will end up being wrapped in some kind of container at all. It looks more like we\u2019re styling the leading label using the trailing label somehow, which really isn\u2019t the case.<\/p>\n
While we could attempt to solve that clarity problem with more verbose API naming, the core issue would still remain \u2014 that the modifier-based version doesn\u2019t properly show what the resulting view hierarchy will be in this case. So, in situations like the one above, when we\u2019re wrapping multiple siblings within a parent container, opting for a view-based solution will often give us a much clearer end result.<\/p>\n
On the flip side, if all that we\u2019re doing is applying a set of styles to a single view, then implementing that as either a \u201cmodifier-like\u201d extension, or using a proper ViewModifier<\/code> type, will most often be the way to go. And for everything in between \u2014 such as our earlier \u201cfeatured label\u201d example \u2014 it all really comes down to code style and personal preference as to which solution will be the best fit for each given project.<\/p>\n
Just look at how SwiftUI\u2019s built-in API was designed \u2014 containers (such as HStack<\/code> and VStack<\/code>) are views, while styling APIs (such as padding<\/code> and foregroundColor<\/code>) are implemented as modifiers. So, if we follow that same approach as much as possible within our own projects, then we\u2019ll likely end up with UI code that feels consistent and inline with SwiftUI itself.<\/p>\n
I hope that you found this article interesting and useful. Feel free to find me on Mastodon<\/a>, or contact me via email<\/a>, if you have any questions, comments, or feedback.<\/p>\n
Thanks for reading!<\/p>","protected":false},"excerpt":{"rendered":"
One of the most interesting aspects of SwiftUI, at least from an architectural perspective, is how it essentially treats views as data. After all, a SwiftUI view isn\u2019t a direct representation of the pixels that are being rendered on the screen, but rather a description of how a given piece of UI should work, look, […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"rop_custom_images_group":[],"rop_custom_messages_group":[],"rop_publish_now":"initial","rop_publish_now_accounts":[],"rop_publish_now_history":[],"rop_publish_now_status":"pending","footnotes":""},"categories":[1,15],"tags":[],"class_list":["post-9740","post","type-post","status-publish","format-standard","hentry","category-explore","category-world"],"_links":{"self":[{"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/posts\/9740","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/comments?post=9740"}],"version-history":[{"count":0,"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/posts\/9740\/revisions"}],"wp:attachment":[{"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/media?parent=9740"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/categories?post=9740"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/handoli.com\/index.php\/wp-json\/wp\/v2\/tags?post=9740"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}