Data Essentials in SwiftUI

Hello and welcome to WWDC.

Hello, and welcome to Data Essentials in SwiftUI. I'm Curt Clifton, an engineer on the SwiftUI team. Later I'll be joined by my friends and colleagues, Luca Bernardi and Raj Ramamurthy.

We're going to cover three main areas in this talk. I'll talk about getting started on the data flow in your SwiftUI app, and cover topics like State and Binding. Then Luca will discuss how you can build on those ideas and more to design the data model for your app. Finally, Raj will share techniques for integrating your data model into your app.

Along the way, we'll discuss the life cycle of a SwiftUI view and share several cool, new features that make it even easier to model your data. We'll also help you develop a deeper understanding of how value and reference types in Swift interact with data flow in SwiftUI.

I'll be walking through some basic data flow features in SwiftUI, and we'll cover some questions you should ask yourself whenever you create a new SwiftUI view.

Luca is really into book clubs. He's so into them that he decided he needed an app to keep track of what each of his clubs is reading and take some notes for their next meeting. I enjoy reading too, and thought it would be fun to work on an app together.

To get started, I want to prototype the view that represents a book I'm reading.

When I start on a new view in SwiftUI, there are three key questions I like to think about.

What data does this view need to do its job? In this example, the view needs a thumbnail of the book cover, the title, the author's name, and the percentage of the book that I've read.

How will the view manipulate that data? This view just needs to display the data. It doesn't change it.

Where will the data come from? This is the "Source of Truth".

In the examples throughout this talk, Luca, Raj and I will use this badge to label the source of truth.

Ultimate, as we'll see, this question of the source of truth is the most important one in the design of your data model.

Let's build out this view and see what its source of truth should be.

So what data does this view need to do its job? The book value provides the name of the cover image, the author and the title.

The progress value provides the percent complete.

And how will the view manipulate this data? It just displays the data, it doesn't change it, so these can be "let" properties.

And where will the data come from? It will be passed in from the superview when the BookCard is instantiated.

The source of truth is somewhere farther up the view hierarchy. The superview passes the true data in when it instantiates a BookCard.

A new BookCard is instantiated every time the superview's body executes. The instance lives just long enough for SwiftUI to render it, then it's gone.

We can visualize the internal structure using a diagram. The boxes on the left represent the SwiftUI views that are composed to build this BookCard.

The capsules on the right represent the data that's used to render the views. We'll return to diagrams like this throughout the talk.

Next, I'd like to look at a slightly more interesting view. When I tap on a book, the app takes me to this screen where I can review my progress. I want to add a way to update my progress, and add notes when I tap on the "Update Progress" button. Something like this.

Let's look at how the parent view and this sheet work together.

We'll focus on how the sheet is presented.

When the user taps the "Update Progress" button, we'll call the presentEditor method. It will mutate some state to cause the sheet to appear.

What data does this view need to control the presentation of the sheet? We need a Boolean to keep track of whether the sheet is presented, and we need a String to keep track of the note, and a Double to track the progress.

Whenever I have multiple related properties like this, I like to pull them out into their own struct.

Besides making BookView more readable, there are two other great things about this approach. We get all the benefits of encapsulation. EditorConfig can maintain invariants on its properties and be tested independently.

And because EditorConfig is a value type, any change to a property of EditorConfig, like its progress, is visible as a change to EditorConfig itself.

Our next question is, how will the view manipulate this data? When the "Update" button is tapped, we'll need to set isEditorPresented to "True" and update progress to match the current progress.

Because we extracted the state into the EditorConfig struct, we can make it responsible for those updates, and just have the BookView ask the EditorConfig to do the work.

Then, we'll add a mutating method to EditorConfig, like so.

And where will the data come from? Well, the editor configuration is local to this view. There isn't some parent view that can pass it in, so we need to establish a local source of truth. The simplest source of truth in SwiftUI is State.

When we mark this property as State, SwiftUI takes over managing its storage. Let's look at that as a diagram.

Again, we have the views represented by these boxes on the left, and the data by a capsule on the right.

Notice that the capsule has a thick border. I'm using this border to indicate data that's managed by SwiftUI for us.

Why is that important? Well, remember that our views only exist transiently. After SwiftUI completes a rendering pass, the structs themselves go away.