A Native SwiftUI Collection View: LazyVGrid and LazyHGrid
In 2019, Apple introduced a change to the way developers could design apps for the Apple ecosystem. The launch of SwiftUI began a long process of change that arguably was well overdue. It has dramatically benefited developers’ productivity and engagement with the platform. And now it’s much simpler to create beautiful UI for our users.
However, during that first launch with Xcode 11, something crucial was missing in the development toolset. There was no out-of-the-box collection view to display views. That omission has thankfully been corrected since the Apple worldwide developers’ conference of 2020. Nevertheless, developers had to rely on custom solutions to display their views in their new SwiftUI-powered apps.
In this article, we’ll explore the collection views available to us in SwiftUI: LazyVGrid and LazyHGrid. You’ll work on a simple implementation to better grasp the concepts introduced in this article. You’ll also customize the appearance of these elements. And finally, you’ll perform some testing to ensure the code stays functional.
A Quick Word on SwiftUI Workflow
Before you jump into any code, let’s briefly explore what a new SwiftUI project is in Xcode.
As soon as you produce a new SwiftUI project, you’ll notice that your template project includes a ContentView.swift file and an <APP_NAME>App.swift file. These files are the essential SwiftUI project. They’re relatively simple to understand because all SwiftUI view files have similar structures.
- There’s a ContentView, containing a “body” variable that defines the design of the view.
- Also, there’s a PreviewView to display the code in the previewer as it would on the actual device.
To modify your view, you can add your code inside the body variable. Notice that there’s already a TextView with our familiar “Hello World!” in it.
Now, you can work on that body variable to create your example.
But what if you have limited experience working with Swift and still feel a bit lost? In that case, please consider diving into this extensive documentation here.
As Apple describes it, a grid is a collection view that enables the layout of elements in a particular format for navigation and interaction. This description covers ScrollViews, Stacks, Lists, and Grids.
Lazy grids—and lazy stacks, for that matter—are specialized collection views that can load their elements when they’re needed for display. Therefore, LazyVStacks, LazyHStacks, LazyVGrids, and LazyHGrids are much less resource intensive than standard Stacks. And that makes them a lot more flexible for the developer.
That being said, throwing a Lazy view everywhere isn’t always the best course of action. After all, there’s a tradeoff in the complexity of implementing these elements compared with their more straightforward siblings. So, consider the suitable application depending on the requirements.
A LazyVGrid is a container view that displays its views in a vertical arrangement for interaction. It loads the items on demand, depending on how the user consumes them.
An example of a LazyVGrid would look like the following.
As you can see, this code is relatively straightforward. We have two variables defined: an array of 50 items and an array of GridItems that determine the configuration of the grid. Don’t worry if you don’t understand the code yet. We’ll dive into that in a minute.
Inside the body, the LazyVGrid is embedded in a ScrollView. This lets the user interact with the grid and scroll them to display. The LazyVGrid constructor has two parameters you must pass: the column structure and the padding between the items.
Inside the LazyVGrid, you have the structure that processes the views from a collection to display. In this case, it’s a ForEach.
Finally, you have an Image view that creates the icons displayed in the list.
Here’s the resulting view:
Notice that it creates a simple, vertically scrollable list with one column.
These items will be initialized as you scroll. And that saves the app the processing time and memory needed to have all these items initialized on creation.
Let’s keep moving.
Like the LazyVGrid, a LazyHGrid is a container view that displays its views horizontally and loads its items when needed.
Now, let’s see how a LazyHGrid would look in code.
That doesn’t look much different, does it?
That’s right. A LazyHGrid follows basically the same structure as a LazyVGrid, with some minor differences.
For one, the ScrollView needs to be defined as horizontal scrolling. Additionally, the LazyHGrid contains different constructor parameters. In this case, they are rows and alignment. That’s pretty self-explanatory.
Those changes would yield the following view.
Notice that now the items are centered vertically and scroll horizontally. Try it out!
All right! That’s pretty neat.
Now, let’s dive a little deeper into the nitty gritty of how the GridItem sets up the layout of the grids.
A GridItem is an additional item that describes the layout of the LazyVGrid and LazyHGrid. It’s an interface of sorts so that your grids can correctly display the items.
This element is pretty helpful because LazyVGrid and LazyHGrid are supposed to handle any view. However, to achieve that level of flexibility, you’ll need to provide a bit more information about your objects.
If you go back to your first code example, you can see that the GridItem config instance is defined as fixed. This tells the LazyVGrid to display the items with a fixed column size that spans over the whole width of the view. Moreover, since there’s only one instance of the GridItem in the config variable, the LazyVGrid will display only one column. Therefore, adding another GridItem will result in a second column, and so on.
Now, here are the possible configurations for the GridItem according to Apple’s documentation:
- Fixed: This is a single item with the specified fixed size.
- Flexible: This is a single flexible item. The size of this item is the size of the grid with spacing, and inflexible items removed, divided by the number of flexible items clamped to the provided bounds.
- Adaptive: Multiple items in the space of a single flexible item. This size case places one or more items into the space assigned to a single “flexible” item, using the provided bounds and spacing to decide exactly how many items fit. This approach prefers to insert as many items of the minimum size as possible but lets them increase to the maximum size.
To demonstrate how this works, let’s talk about how you can tweak your grid appearance.
So, what would happen if you used, say, a combination of these?
As you can see in the code above, I’ve added a flexible GridItem to the configuration. This setup results in the following:
Notice that the first column has a set size, and the second column spans to occupy the rest of the space. Also, you can set a maximum size to the flexible configuration.
All right! How about the adaptive configuration?
Let’s see how you can use adaptive to let the LazyVGrid position the items as they fit horizontally and vertically.
In this case, you need to set only one GridItem configuration.
As you can see, this configuration accommodates as many columns as there could fit horizontally and then spans the rest of the content vertically. That’s pretty useful for a more dynamic and responsive layout, such as photo galleries or resizable views.
Pretty great, right?
Test Your Grids
Finally, let’s create a simple testing routine to ensure the quality of your work.
To do that, you’re going to move to the Test_iOS.swift file and work on the testExample method. Once you’re there, you can add the following code to test that the grid displays correctly and responds as expected.
This is a very simplistic test scenario. Ideally, you should be more thorough with your tests. For that purpose, I recommend considering Waldo's extensive toolset for UI testing. No coding is required, which is excellent for non-developers. There’s a free trial and a helpful blog.
Navigating the extensive toolset available in Apple’s ecosystem can be tiring and overwhelming at times. Sometimes, the solution you’re looking for isn’t available, or there just isn’t enough documentation at the moment. That was certainly the case in 2019. Nevertheless, SwiftUI continues to mature steadily, and more tools become part of your set. This lets you bring more elegant and functional solutions to your users.