Just finished watching the Data Essentials in SwiftUI session, and I had a few questions relating to connecting the views to the data model.
In particular, one example from the video was this:
I assume that the initializer for ReadingListStore() would connect to any arbitrary data backing. If we're using CoreData, how does @StateObject wrapper on the store relate to/impact the use of @FetchRequest property wrapper on CoreData requests? Should we no longer use @FetchRequest because @StateObject is handling ensuring that changes to store are reflected in the UI?
Second, the video used this example to emphasize the difference between @ObservedObject and @StateObject:
What I didn't quite understand was whether even with the @StateObject the store was being recreated every time that ReadingList view appeared on screen (but it's preventing the store from being recreated every time the view is redrawn while on screen)? If the store is drawing from some data model elsewhere, either way the issue is one of efficiency, not data loss, right?
Finally, I had a question about data relating to the app - scene distinction. If our app doesn't have a need to show the same data side by side in split screen (iPadOS) or in different windows (Mac), where is the best place to do our logic so that we get a new project/document/etc anytime a user opens a new window (ie creates a new scene)? In other words if the data model is for example a canvas with a bunch of shapes on it, where should we put the logic for having the app show a new canvas every time a new scene is created? If we did something like this:
Would that allow us to assume that every time ReadingListStore() is called, we are getting a new scene?
In particular, one example from the video was this:
Code Block @main struct BookClubApp: App { @StateObject private var store = ReadingListStore() var body: some Scene { WindowGroup { ReadingListViewer(store: store) } } }
I assume that the initializer for ReadingListStore() would connect to any arbitrary data backing. If we're using CoreData, how does @StateObject wrapper on the store relate to/impact the use of @FetchRequest property wrapper on CoreData requests? Should we no longer use @FetchRequest because @StateObject is handling ensuring that changes to store are reflected in the UI?
Second, the video used this example to emphasize the difference between @ObservedObject and @StateObject:
Code Block struct ReadingListViewer: View { var body: some View { NavigationView { ReadingList() Placeholder() } } } struct ReadingList: View { @StateObject var store = ReadingListStore() var body: some View { // ... } }
What I didn't quite understand was whether even with the @StateObject the store was being recreated every time that ReadingList view appeared on screen (but it's preventing the store from being recreated every time the view is redrawn while on screen)? If the store is drawing from some data model elsewhere, either way the issue is one of efficiency, not data loss, right?
Finally, I had a question about data relating to the app - scene distinction. If our app doesn't have a need to show the same data side by side in split screen (iPadOS) or in different windows (Mac), where is the best place to do our logic so that we get a new project/document/etc anytime a user opens a new window (ie creates a new scene)? In other words if the data model is for example a canvas with a bunch of shapes on it, where should we put the logic for having the app show a new canvas every time a new scene is created? If we did something like this:
Code Block @main struct BookClubApp: App { var body: some Scene { WindowGroup { ReadingListViewer() } } } struct ReadingListViewer: View { @StateObject var store = ReadingListStore() var body: some View { NavigationView { ReadingList() Placeholder() } } }
Would that allow us to assume that every time ReadingListStore() is called, we are getting a new scene?