iOS

Using View Model Protocols to manage complex SwiftUI Views

March 11, 2021
Using View Model Protocols to manage complex SwiftUI Views

The Problem

Managing complex screens or views that depend on asynchronous services or the need to pull in state from across your app can be tricky to get right. The most common way to address this in SwiftUI is by abstracting that logic into a dedicated view model for that piece of UI. Usually, the view model and view will look something like this:

`swift struct ComplexView: View { @ObservableObject var viewModel: ComplexViewModel

var body: some View {

ScrollView {
  if case .loaded(let items) = viewModel.state {
    VStack {
       ForEach(items) { item in
        ItemView(item: item)
      }
    }
  } else {
    LoadingView()
  }
}
.onAppear { viewModel.load() }

} } `

`swift final class ComplexViewModel: ObservableObject { @Published var state: LoadingState = .loading

func load() {

// Load some data

// URLSession.shared.dataTaskPublisher ... 

} } `

This abstraction is good - it makes the screen function - but it has one major flaw: you can no longer create a meaningful preview of ComplexView. The view requires an instance of its ComplexViewModel in order to function and as written that view model depends on the network to load its data. You will encounter a similar problem if you have a view model that is backed by CoreData or some other persistence layer.

A Solution

One possible solution would be to allow creating a ComplexViewModel instance with a mocked out Network or Persistence layer. While this may work, I find the extra ceremony needed to maintain that abstraction a little cumbersome. All we really need is a way to provide data to a ComplexView instance. The View itself doesn't need to know how that data got there. We can accomplish this by hiding our view model behind a protocol.

ComplexViewModel is now a protocol `swift protocol ComplexViewModel: ObservableObject { var state: LoadingState { get } func load() } `

The content of ComplexView is largely the same, but now must be generic over its view model type because the ComplexViewModel protocol extends ObservableObject which has an associated type and therefore can only be used as a generic constraint. `swift struct ComplexView<ViewModel: ComplexViewModel>: View { @ObservableObject var viewModel: ViewModel // same as before } `

The old view model class has been renamed to NetworkBackedComplexViewModel as a concrete implementation of ComplexViewModel that loads from the network `swift final class NetworkBackedComplexViewModel: ComplexViewModel { // same as before } `

We can similarly create another class that implements the ComplexViewModel protocol for use in previews. `swift final class PreviewComplexViewModel: ComplexViewModel { let state: LoadingState

init(state: LoadingState) {

self.state = state

}

func load() { } // do nothing } `

Takeaway

With this protocol abstraction we can now create meaningful previews of our otherwise complex screens, even setting up multiple variations of PreviewComplexViewModel in different states. `swift struct ComplexView_Previews: PreviewProvider { static var previews: some View {

Group {
  ComplexView(
    viewModel: PreviewComplexViewModel(state: .loading)
  )
  ComplexView(
    viewModel: PreviewComplexViewModel(state: .loaded([]))
  )
}

} } `

I think this makes for a nice way to reason about a screen: Describe the requirements for a piece of UI via a protocol Write the view code against that protocol * Create a class that implements the protocol and pulls data from elsewhere in your app

We can leverage this decoupling of our screen from how it gets its data by creating additional flavors of view model (CacheBackedComplexViewModel, DatabaseBackedComplexViewModel, etc.). With this we are enable to reuse a complex piece of UI in different contexts. You can potentially even hide these implementations behind a Swift package if you wanted to keep your UI and networking or persistence layers decoupled in that manner.

This idea is still a little abstract but I want to put it out there as we continue to better understand and use SwiftUI. What do you think? How are you managing complex UI in your SwiftUI apps?

Jeff Kloosterman
Jeff Kloosterman
Development Practice Co-Lead

Stay in the loop with our latest content!

Select the topics you’re interested to receive our new relevant content in your inbox. Don’t worry, we won’t spam you.

Growing with Glue Work
Team

Growing with Glue Work

July 21, 2021

Co-Written By Kylie Martinez and Amanda Clouser

Read more
Android Development Process

The Lowdown on Android Lint

August 13, 2019

Read more
Michigan Software Labs Named One of the Country's Best Small and Medium Workplaces by Fortune copy
Press Release

Michigan Software Labs Named One of the Country's Best Small and Medium Workplaces by Fortune copy

October 16, 2020

Michigan Software Labs has been named as one of the 100 Best Small and Medium Workplaces based on an independent survey by consulting firm Great Place to Work® and Fortune Magazine. Michigan Software Labs came in 64 on the list.

Read more
View more articles