∞
Building, Testing, and Scaling With SwiftUI Part 2: Composing View Models
Part 1: Building Previewable Views In the previous post of this series I discussed how important it is for views to clearly define their dependencies in a way that can be stubbed out. We did that by making our view generic over a view model protocol, then having both a production and a stub version of the view model. It looked something like this:
protocol PokemonListViewModelProtocol: Observable { var pokemonList: [Pokmeon] { get } func fetchPokemon() async } struct PokemonList<ViewModel: PokemonListViewModelProtocol>: View { @State var viewModel: ViewModel init(viewModel: ViewModel) { _viewModel = State(wrappedValue: viewModel) } // .
∞
Building, Testing, and Scaling With SwiftUI Part 1: Building Previewable Views
One aspect of SwiftUI that is crucial to my workflows is the SwiftUI Preview system. Previews are an incredibly powerful and sophisticated tool, intelligently recompiling only the code which has been modified, in order to achieve a blazing fast edit-refresh cycle. If you change the String value you pass to a SwiftUI Text view, Previews will recompile that specific view only and nothing else in your view hierarchy, dynamically swapping it in at runtime.
∞
Why I'm Not Using SwiftData (Yet)
Apple’s SwiftData framework was announced this year at WWDC and it’s what we’ve all been waiting for. A persistence mechanism from Apple, written entirely in Swift for Swift… kind of. The fact is that it’s still the old CoreData framework under the hood, with a sugary layer of Swift on top. While that bodes well in some senses because CoreData is battle-tested, it also means that we continue to carry with us many of CoreData’s idiosyncrasies, which can be either good or bad depending on where you stand.