Last year, I posted my presentation video and slides for the CocoaHeads Aachen talk “Making Your App Extensible with JavaScriptCore”. Today I read about Simon Willisons’s presentation annotation tool. It’s a simple HTML file where you can put your slides, have Tesseract generate alt-text for each, and annotate the whole thing with simple Markdown. The generated output is HTML. It is genius. I love it, and here’s the slides + transcript (which I happen to have from editing the video anyway) of the JSCore talk.
I hadn’t looked at SwiftData at all until now. The thumbnail read “Store Images in SwiftData”, and I was immediately worried: I recall it’s a bad idea to store megabyte upon megabyte of binary data inside the DB, assuming it’ll be using a BLOB column.
Turns out that SwiftData isn’t that simplistic and my assumption is wrong if configured properly!
SwiftData models can manage storage outside to the database. That’s what @Attribute(.externalStorage) is for: “Stores the property’s value as binary data adjacent to the model storage.”
I ran into this, too, recently and wondered how everyone’s dealing with this. Because this is so annoying, I expected more outcries on the interwebs every day.
Maybe nobody is writing tests?
Either way: These helpers look very nice, and I’ll try them for sure. Should be part of the XCTest libray in my opinion. I seriously wonder why there’s no async XCTest assertion functions for this already.
If you’re just running into this for main actor isolation: One workaround that got suggested to me is to annotate the XCTestCase subclass itself with @MainActor to circumvent having to await isolated calls everywhere. (That doesn’t help for non-main actor-isolated calls, obviously.)
The whole responder chain is traversed like the following, via the documentation for NSApplication.sendAction(_:to:from:): First, NSResponder.respondsToSelector(_:) is called to check if the current candidate is a match; if this returns false, NSResponder.supplementalTarget(forAction:sender:) is sent to get to another receiver to delegate the call to.
Remember when I wrote about MVVM and eventually in 2015 produced this: I learned that the “view model” in the architectural style of MVVM is a “model of the view” instead of a “model for the view”. Let me explain the difference and the benefits of being able to chose between both.
Say you have a view component. You can control which subcomponents it displays for maximum reuse. One day, you end up configuring the available effects, or actions, of the view component. Let’s say it’s something like this, a made-up example: The delete case with its associated value sticks out a bit.