trozware/swiftui-data-flow

An Xcode project for demonstrating SwiftUI data flow.

Sarah Reichelt

TrozWare

• Mac developer and author.
• Lover of Apple computers and devices.
• Swift & SwiftUI enthusiast.
• Unofficial Mac app dev evangelist.

• Author of macOS by Tutorials
• Author of macOS Apprentice

Read my blog posts at https://troz.net
Follow me on Mastodon, other links at Linktree

swiftui-data-flow's Issues

PersonList without @Bindable

Hi! I really enjoyed your article!

I think I might have another way to setup the example in ObservableObject & @ObservedObject - Part 2. I wasn't sure how else to share this so I thought I'd just create an issue here.

I think PersonDetailView(person: self.$personList.persons[index]) is actually creating a binding to your PersonListModel, rather than to the PersonViewModel itself. This means that anytime the PersonViewModel is changed on the next screen, it will update the PersonListModel, which will cause PersonListView to update. This means that the entire list will need to be updated any time a person is modified.

Instead, I think your first approach might have been better - where PersonDetailView doesn't require a binding, but instead observes a PersonViewModel with @ObservedObject. Then to make sure the changes to the PersonViewModel are reflected in the PersonListView, you could create a new View for the list rows and have this observe your PersonViewModel:

struct PersonRow: View {
    @ObservedObject var person: PersonViewModel

    var body: some View {
        Text("\(person.first) \(person.last)")
    }
}

...
ForEach(personList.persons) { person in
    NavigationLink(destination:  PersonDetailView(person: person) ) {
        PersonRow(person: person)
    }
}
...

Now whenever a person is modified, only the view for that row is updated, instead of the entire list.

Suggestion about ObservableObject & @ObservedObject - Part 2

Hi,
Thanks for writing the "SwiftUI Data Flow" article.

As a follow-up question, why don't you pass the personList ObservedObject to the DetailView? You also have a UUID for every person, which you can use to identify the element you want to update in the personList.persons array.

The main view NavigationLink can pass that data:

ForEach(personList.persons) { person in
    NavigationLink(destination: PersonDetailView(personList: personList, personID: person.id) ) {
        Text("\(person.first) \(person.last)")
    }
}

The PersonDetailView:

struct PersonDetailView: View {
    @ObservedObject var personList: PersonListModel
    let personID: UUID

    var personIndex: Int {
        //Optional unwrap with fatalError().
        personList.persons.firstIndex(where: { $0.id == personID })!
    }

var body: some View {
...

You can update values like this:

TextField("Address", text: $personList.persons[personIndex].address)
    .autocapitalization(.words)

And both the PersonDetailView and the PersonListView values will be updated.

selectedPizzaName binding versus property

I truly enjoyed your article and code. Thanks!!!

In struct PizzaNamePickerRow

// The following binding is not needed.
@Binding var selectedPizzaName: PizzaName

// Instead, as the value is not mutated, it can be a simple property.
let selectedPizzaName: PizzaName

The PizzaNamePickerRow view is the label for the Button in PizzaNamePicker. The original code uses the $selectedPizzaName for the binding:

Button(action: { self.selectedPizzaName = pizzaName }) { PizzaNamePickerRow(selectedPizzaName: self.$selectedPizzaName, pizzaName: pizzaName) }
Instead, it should simply use the property value:

Button(action: { self.selectedPizzaName = pizzaName }) { PizzaNamePickerRow(selectedPizzaName: self.selectedPizzaName, pizzaName: pizzaName) }

However, that the actual binding is needed because the button action mutates the value.

@Binding var selectedPizzaName: PizzaName
... and ...
Button(action: { self.selectedPizzaName = pizzaName })

Observable 1 but with an array of colors

Not really an issue, its the only place I can make a comment on the source.

I wanted to see if everything worked if I turned foreground colors into an array as opposed to three different @published variables:

#if false
    @Published var foregroundRed = 0.0
    @Published var foregroundGreen = 0.0
    @Published var foregroundBlue = 0.0
#else
    @Published var foreground: [Double] = [0, 0, 0]
#endif

Glad to say it works fine. I believe using structs and collections is a more real-world case.