Oddbean new post about | logout
 GM Nostr!

Fighting with SwiftData this morning. When using predicate's for queries, etc it absolutely does not like computed properties. A pain in the ass. I really want SwiftData to work though because it so tightly integrates with SwiftUI. 
 I spent an hour or 2 looking at swift data and decided it was absolutely shit

Maybe I am wrong, but progress was made 
 Yeah, it's missing somethings that would make life easier like conditional update/insert, explicit indexes ( I think it does some automatic indexing) and dealing with migrations seems more complicated than it should be. That said, it integrates so nicely with SwiftUI for me it's hard to not give it a go. Im going to keep going with it for now. The unknown for me is performance. I haven't had any issues there yet, but I haven't pushed it.

My fallback option will probably be Realm which I've used in the past and is quite nice. 
 GM! I’m finding SwiftData to be a bit difficult to work with, too. Are you using value transformers? For the time being, I’m using SwiftData as a semi-dumb data store for Nostr event kinds and local app settings, and I load everything into my in-memory cache on app launch. I hope to integrate more closely to SwiftData as Apple improves it over time. 
 I haven't used value transformers before.  Im going to look into them though.

Right now I have a handful of models that I create from events as they come in, then store them into SwiftData, but that code is getting overly complicated. So before I dig too deep Im experimenting with something that may or may not work.

Instead of having all these different SwiftData models, Im simply storing a single model for the event. Almost as it would be stored on a relay. One addition to the model is that I serialize the tags into a single special formatted string since trying to use a predicate on nested arrays might get messy.

The idea is that this keeps my data model more simple as well as code path where I store these events.

Then I will use the queries to map the stored event's into their more detailed object where needed.

The unknown I have now is if doing this will cause too much overhead on the UI. I just don't know yet, but my code is early enough that I can try it and if it works as I hope it does it simplifies the code around this a lot. 
 Sounds similar to what I’m doing with the storage part. I store the serialized JSON of the Nostr event (and use a value transformer to get the deserialized object) and which relays the event was found into a single model. Then I map those to specific event kind classes on app launch.