Tried implementing this a few different ways in a ListView -> DetailView case and always hit the same wall. While the child context does work as a scratch pad in the view model, and saves changes on calling persist, I can't seem to get those changes to trigger a refresh on the initial ListView. Unit tests confirm it's working and relaunch the app shows the change. Any ideas?
I'm running into the same issue. One thing that seems to work is to turn the ViewModel into an ObservableObject and then adding objectWillChange.send() on any code within the viewModel that changes the coreData model. This doesn't take advantage of the NSManagedObjects being observable though so hopefully there is a more straightforward path that we are missing... :)
Thank you Donny. Very clear and thoughtful presentation. I like your emphasis on not fighting the framework. The child context concept is quite helpful. I implemented a solution to use one view for both creating and updating, but that alway felt like dirty hack with too many lines of code. My refactoring starts straight away.
Too many SwiftUI mistakes in the code examples. 25:57 Although EditViewModel is a struct, inside its init it inits a context object which we must not do in body. Instead, the child context should be created in an action. 28:42 should be @Binding not @State. Although to be honest view models in SwiftUI is unnecessary, the View structs are actually the model for the UIViews on screen and the property wrappers give them object semantics. Usually we call @State structs that group vars simple Configs, e.g. EditConfig
Disagree here. For the childViewContext to work it we need to keep a reference to it somewhere, and in this case a ViewModel is a better choice as it can be thunked into a StateObject and only instantiated when needed.
Finally I mange to fix my previews with Core Data. Thank you for sharing!
thanks for video! BTW I use CoreData Studio for my data monitoring
I’m a complete beginner, but watch the whole video and subscribed to channel, so I can come back whenever I lean more!
Thanks. Perhaps I won’t be abstracting core data away just yet. I’m going to go with the flow! Thanks
Donny killed it, great presentation great info and seasoned tech understanding
Thank you for the multi context solution. I was looking for this for a while...
Thank you for your time to upload such great content and provide it for us for free. Awesome!
Tried implementing this a few different ways in a ListView -> DetailView case and always hit the same wall. While the child context does work as a scratch pad in the view model, and saves changes on calling persist, I can't seem to get those changes to trigger a refresh on the initial ListView. Unit tests confirm it's working and relaunch the app shows the change. Any ideas?
I'm running into the same issue. One thing that seems to work is to turn the ViewModel into an ObservableObject and then adding objectWillChange.send() on any code within the viewModel that changes the coreData model. This doesn't take advantage of the NSManagedObjects being observable though so hopefully there is a more straightforward path that we are missing... :)
This was very useful.
Thank you!
Is the topic 'passing NSManagedObject to childViewContext' part of Practical Core Data book ?
Great talk Donny!
Thank you Donny. Very clear and thoughtful presentation. I like your emphasis on not fighting the framework.
The child context concept is quite helpful.
I implemented a solution to use one view for both creating and updating, but that alway felt like dirty hack with too many lines of code. My refactoring starts straight away.
Excellent video
Thanks Donny!
Is Core Data is ❤️ and CloudKit 💪
Too many SwiftUI mistakes in the code examples. 25:57 Although EditViewModel is a struct, inside its init it inits a context object which we must not do in body. Instead, the child context should be created in an action. 28:42 should be @Binding not @State. Although to be honest view models in SwiftUI is unnecessary, the View structs are actually the model for the UIViews on screen and the property wrappers give them object semantics. Usually we call @State structs that group vars simple Configs, e.g. EditConfig
Disagree here. For the childViewContext to work it we need to keep a reference to it somewhere, and in this case a ViewModel is a better choice as it can be thunked into a StateObject and only instantiated when needed.