|
I've been trying to figure out SwiftData, and am being driven well nigh crazy. I've built a toy model to demonstrate:
In short, what's the correct way to pass Observable objects into child views so that the view receives observation updates when the relevant object properties' setters get called? The docs seem to suggest it should magically happen, and that no property wrappers are needed, but my experience is anything but. I've come across a number of similar examples on stack overflow, but no convincing solutions - the closest I've come is someone suggesting to use a separate ObservableObject in a view model, and then to copy changes to a published variable, which doesn't at all seem in the spirit of what Apple is getting at with this. Am I just missing something obvious? Thanks in advance, Dominic --- CODE --- Model:
Layer 1 view:
Layer 2 view:
|
|
Hi @GerardBailey, I'm afraid your answer reads just like something generated by GPT4 - apologies if it isn't, but there are some giveaway phrases that ring alarm bells for me (e.g. the "Here are some suggestions and insights that might help you..." boilerplate, which GPT prefixes to most such answers), and I have a pretty good depth of experience building on generative models. Also, you've got a mishmash of things that are valid along with things that are clearly out of date or already mentioned in my post:
Does anyone else have any targeted advice on my specific problem? Thanks, Dominic |
|
I would suggest to follow this logic. When you pass your UPDATE My previous suggestion works, however there is redundant code in it, due to using NOW ABOUT THE REASON why your code did not work Paul mentioned that this might be a bug in that article. https://www.hackingwithswift.com/quick-start/swiftdata/how-to-save-a-swiftdata-object Namely:
1. The App File
2. Data Model File
3. Parent View File
4. Child View File
5. Grandchild View File
|
|
Hi @ygeras, I just wanted to say a massive thank you for this. It's incredibly helpful, and I've now got everything working as intended. It's really frustrating that the basic functionality Apple touts for SwiftData is so flaky, and it feels so wrong to have to insert new items into the model context in some places, but in others imperatively set a relationship object's properties to cause the change notification to be sent. I've also discovered that in at least one example (a ScrollView), deletion of a grandchild works fine, but to get the view to update you have to first remove the object from the child.grandchildren array, which again feels like a bit of an antipattern. I was about to dispair of SwiftData and revert to CoreData, but you've saved me. It still feels like a massive ergonomic improvement, event with workarounds required. Any no worries at all about the precision - it's very helpful indeed, and definitely makes everything clearer. Thanks again! Dominic |
|
Hi @dbtl88! You're more than welcome! Glad to hear that such approach helped to solve your challenge. Your kind words are really appreciated.
Talking about my sample code, as I am using "empty view" and "list view" in children and grandchildren. One may notice that once the last item in array is removed, the view does not switch automatically to "empty view". So as you mentioned you have two options there:
and upon deletion refresh the view
|
SPONSORED Join a FREE crash course for mid/senior iOS devs who want to achieve an expert level of technical and practical skills – it’s the fast track to being a complete senior developer! Hurry up because it'll be available only until February 9th.
Sponsor Hacking with Swift and reach the world's largest Swift community!
This topic has been closed due to inactivity, so you can't reply. Please create a new topic if you need to.
All interactions here are governed by our code of conduct.
Link copied to your pasteboard.