Configuring SwiftUI views

Tram Ho

One of the key ways that SwiftUI is different from Apple’s previous UI frameworks is how to create and configure its views. In fact, it can be argued that when using SwiftUI, we actually never create any views – instead we simply describe what we want, and then the system will Realistic rendering processing. In this article, let’s look at a few different techniques to structure the view description and the pros and cons of each approach that gives us code structure and flexibility.

Initializers, modifiers and inheritance

In general, there are three different ways to configure the SwiftUI view – by passing arguments to its constructor, using modifiers, and passing the surroundings. For example, here, we configured Text view to act as the body of TitleView – using both its constructor and applying modifiers to it to change its font and text color:

The above is an example of direct configuration, because we set and modify our Text view by calling methods directly on it. However, SwiftUI also supports indirect configuration, because many different attributes and modifiers are automatically passed down through each given view hierarchy. The type of configuration inherited in an indirect way can be extremely useful in situations when we want multiple sibling views to use the same type of configuration or style – as in the latter case, in which we configure both Text and List to display all text using monospaced font, simply by assigning that font to its parent VStack:

Let’s look at another example in which we change the accentColor of the navigation stack just by assigning it to our original NavigationView – this will cause that color to be applied to all child views, including The views are managed by the system, like the navigation bar items we have defined:

However, sometimes we may want to apply a set of styles to a group of views without having to change their relationship with the parent view. For example, suppose we are building a view to display an address in an application, including a series of stacked Text views:

Above, we specified the same style as the first 2 labels, so we have to refactor that code to avoid having to repeat it. In this case, we cannot apply modifiers to the parent view label, because we can only apply given styles to a subset of it. Thankfully, SwiftUI also provides a type of group, which allows us to treat a set of views as a group – without affecting the layout, drawing or their position in our overall view hierarchy. Using this type, we can group our two labels together and then apply our modifier to both labels at the same time:

The strength of the Group is that it applies modifiers directly to its children, not to itself. Compare that to if we were to group our labels using another VStack , this would allow padding and background colors to be applied to that stack, instead of individually for our labels. .

Views versus extensions

As our SwiftUI-based views grow complex, we may need to start using many ways to group and share different configurations and styles, to keep our code easy to operate. So far, we’ve mostly dealt with styles through modifiers, but a major part of our UI configuration is also related to how we structure our views. Suppose that we work on a form that allows the user to register an account in an application. To make our form a bit nicer, we’ve prefixed each textfield with icons from Apple’s SF Symbols library – giving us the following implementation:

Above we are using the same HStack + Image + TextField twice and while it’s not necessarily a problem since we configure two completely different text fields – assuming we also want to turn That combination is an independent component that we can reuse elsewhere in our application. An initial idea of ​​how to do that could be to create a new View type with the icon name and title to display, as well as the @Binding reference to the text property we want to update whenever the text field is modified. edit – as follows:

With the above in mind, we can now return to SignUpForm and replace the previously copied HStack configurations with instances of IconPrefixedTextField new IconPrefixedTextField component:

However, while the above change will allow us to reuse our new IconPrefixedTextField type outside of SignUpForm , will it really improve our code? After all, we don’t really make our signing up form simpler – in fact, our above call site seems to be more complex than it has been before. Instead, take some inspiration from SwiftUI’s API design, and see what it would be like if we implemented the code text view configuration as a View extension. That way, any view can be prefixed to an icon, just call the following method:

With the code above, we can now directly add any SF Symbols icon to SwiftUI’s TextField view – or to any other view – like this:

Modifier types

In addition to writing view extensions, SwiftUI also allows us to define custom view modifiers that are the types that follow the ViewModifier protocol. Doing so allows us to write modifiers that have their own properties, states, and lifecycle – which can be used to extend SwiftUI with all sorts of new functions. For example, suppose we want to add inline validation to our sign up form from before, by converting each text field’s border to green when the user enters a valid string. We can implement it directly in the SignUpForm view, but instead, let’s build that feature as a fully ViewModifier :

Looking at the implementation above, we can see that ViewModifier looks very similar to a view, in that it has the body returns some View . The difference is that the modifier works on existing views (passed as content ), instead of being completely independent. The benefit is that we can now add our new authentication function to any text field (or any view), just like when using the view extension, without asking us to build any type of Which wrapper:

Conclusion

SwiftUI provides several ways for us to structure the UI code and how we can configure different views. Although many of our custom components may be implemented as standalone View types, building our own extensions and modifiers can allow us to share styles and configurations on the code base. in a much lighter way – and can allow us to apply those types to different types of views.

Hope the article will be useful to you.

Preference: https://www.swiftbysundell.com/articles/configuring-swiftui-views/

Share the news now

Source : Viblo