Sorry I wrote this a long time ago. Now I would recommend removing the object the completely and using .task for async/await.

ToDosApp.body.getter shouldn't be initing any objects

Rebooting the simulator fixed the issue for me. They wanted a sysdiagnose which I wasn't able to provide because couldnt recreate the problem so I just closed the feedback.

@erdeszbalazs read that link closely, it says "in your data model type", it isn't for view data, that is what View structs are designed for. Also at 20:50 in Data Essentials in SwiftUI WWDC 2020 they say "Views are very cheap, we encourage you to make them your primary encapsulation mechanism".

StKiril, that example is from the model data section of the documentation so irrelevant to this discussion. The basics are: View data = View structs, State, Bindings, computed vars, .task Model data = Observable, ObservableObject

Where do they recommend doing that? In the App struct (which is only init once) @State doesn't seem any different behavior from let container = ModelContainer.create() In a View struct @State will leak the initialValue object every time the View is init. Maybe they mean use @StateObject?

delete

Since SwiftUI already is a view model you would be better off learning State & Binding instead of trying to build a custom layer of MVVM objects on top of it. That will likely cause the same kind of consistency errors that SwiftUI's use of View structs was designed to eliminate. Try breaking your view data up into View structs, put State in a shared common parent, pass down as let for read only or Binding var for read/write. The body will be called in all cases when the data changes.

Usually you don't need Task.detached. To get a background thread simply move the code to a nonisolated async func in the View struct or move it to a struct that is not MainActor.

Usually you don't need Task.detached. To get a background thread simply move the code to a nonisolated async func in the View struct or move it to a struct that is not MainActor.

Try redesigning your model so you only have one @Query per View. It might mean your model isn't designed correctly. Try to design it based on what you want to show. And its best to compute counts when you save rather than compute them in the UI.

Not just the same format, style, but exactly the same button duplicated an arbitrary number of times. I'm trying to think of a situation where one would want that to happen but haven't thought of one yet.

[post] should fix that, e.g. .navigationDestination(for: Paragraph.self) { [post] paragraph in ParagraphDetail( post: post, paragraph: paragraph) } This way it captures post and not self so it won't be called every time any property of self changes and only if post changes.

Only if post is a struct though. Otherwise you probably don't want to capture it because then ParagraphDetail won't update if a property of post is changed.

Seem it has changed to NSNotification.Name(rawValue: "_SwiftDataModelsChangedInContextNotificationPrivate") but the sets are of type Set<AnyPersistentObject> and AnyPersistentObject is private so we can't get to the objects.