Difference between creating ViewModifier and View extension in SwiftUI

Question

I'm trying to find out what is practical difference between these two approaches. For example:

struct PrimaryLabel: ViewModifier {
    func body(content: Content) -> some View {
        content
            .padding()
            .background(Color.black)
            .foregroundColor(Color.white)
            .font(.largeTitle)
            .cornerRadius(10)
    }
}

extension View {
    func makePrimaryLabel() -> some View {
        self
            .padding()
            .background(Color.black)
            .foregroundColor(Color.white)
            .font(.largeTitle)
            .cornerRadius(10)
    }
}

Then we can use all of them following way:

Text(tech.title)
    .modifier(PrimaryLabel())
Text(tech.title)
    .makePrimaryLabel()
ModifiedContent(
    content: Text(tech.title),
    modifier: PrimaryLabel()
)

Answer 1

I usually prefer extensions, as they get you a more readable code and they are generally shorter to write. I wrote an article about View extensions.

However, there are differences. At least one. With ViewModifier you can have @State variables, but not with View extensions. Here's an example:

struct ContentView: View {
    var body: some View {
        VStack {
            Text("Hello, how are you?").modifier(ColorChangeOnTap())
        }
    }
}

struct ColorChangeOnTap: ViewModifier {
    @State private var tapped: Bool = false
    
    func body(content: Content) -> some View {
        return content.foregroundColor(tapped ? .red : .blue).onTapGesture {
            self.tapped.toggle()
        }
    }
}

Answer 2

All of the approaches you mentioned are correct. The difference is how you use it and where you access it. Which one is better? is an opinion base question and you should take a look at clean code strategies and SOLID principles and etc to find what is the best practice for each case.

Since SwiftUI is very modifier chain base, The second option is the closest to the original modifiers. Also you can take arguments like the originals:

extension Text {
    enum Kind {
        case primary
        case secondary
    }

    func style(_ kind: Kind) -> some View {

        switch kind {
        case .primary:
            return self
                .padding()
                .background(Color.black)
                .foregroundColor(Color.white)
                .font(.largeTitle)
                .cornerRadius(10)

        case .secondary:
            return self
                .padding()
                .background(Color.blue)
                .foregroundColor(Color.red)
                .font(.largeTitle)
                .cornerRadius(20)
        }
    }
}

struct ContentView: View {
    @State var kind = Text.Kind.primary

    var body: some View {
        VStack {
        Text("Primary")
            .style(kind)
            Button(action: {
                self.kind = .secondary
            }) {
                Text("Change me to secondary")
            }
        }
    }
}

We should wait and see what is the BEST practices in new technologies like this. Anything we find now is just a GOOD practice.

Answer 3

I believe the best approach is combining ViewModifiers and View extension. This will allow composition of @State within the ViewModifier and convenience of View extension.

struct PrimaryLabel: ViewModifier {
    func body(content: Content) -> some View {
        content
            .padding()
            .background(Color.black)
            .foregroundColor(Color.white)
            .font(.largeTitle)
            .cornerRadius(10)
    }
}

extension View {
    func makePrimaryLabel() -> some View {
        ModifiedContent(content: self, modifier: PrimaryLabel())
    }
}

Usage

Text(tech.title)
    .makePrimaryLabel()

Answer 4

It may be that there is an advantage in the type signature of the resulting Views when using a ViewModifier. For example if we create the following TestView to display the types of the three variants using this:

struct TestView: View {
    init() {
        print("body1: \(type(of: body))")
        print("body2: \(type(of: body2))")
        print("body3: \(type(of: body3))")
    }
    
    @ViewBuilder var body: some View {
        Text("Some Label")
            .modifier(PrimaryLabel())
    }
    
    @ViewBuilder var body2: some View {
        Text("Some Label")
            .makePrimaryLabel()
    }
    
    @ViewBuilder var body3: some View {
        ModifiedContent(
            content: Text("Some Label"),
            modifier: PrimaryLabel()
        )
    }
}

We can see it yields the following types:

body1: ModifiedContent<Text, PrimaryLabel>
body2: ModifiedContent<ModifiedContent<ModifiedContent<ModifiedContent<ModifiedContent<Text, _PaddingLayout>, _BackgroundStyleModifier<Color>>, _EnvironmentKeyWritingModifier<Optional<Color>>>, _EnvironmentKeyWritingModifier<Optional<Font>>>, _ClipEffect<RoundedRectangle>>
body3: ModifiedContent<Text, PrimaryLabel>

Even if there isn't an advantage during execution it might make debugging a little easier if nothing else.

Answer 5

There is another approach: using View extension and a generic custom view. Using generic custom view resolves the issue that @kontiki mentioned (how to apply it to other views). Below is the code：

struct ContentView: View {
    var body: some View {
        VStack {
            Text("Hello, how are you?").colorChangeOnTap()
        }
    }
}

struct ColorChangeOnTap<Content: View>: View {
    var content: Content
    @State private var tapped: Bool = false

    var body: some View {
        return content.foregroundColor(tapped ? .red : .blue).onTapGesture {
            self.tapped.toggle()
        }
    }
}

extension View {
    func colorChangeOnTap() -> some View {
        ColorChangeOnTap(content: self)
    }
}

While being different, the approach is very similar to the view modifier approach. I suspect this might be what the SwiftUI team originally had and, when they added more features to it, it evolved into view modifier.