Today I am reminded, once again, that #Codable is a terrible #SwiftLang API that should be excised from the language with extreme prejudice.

It's a shame that Swift 6 is already "done”; it would've been the perfect time to do it.

Parsing JSON Data is a fundamental in modern SwiftUI apps. This comprehensive guide covers all the aspects of the Codable protocols in Swift.

#JSON #Programming #Swift #SwiftUI #macOS #iOS #visionOS #Codable
https://matteomanferdini.com/swift-parse-json/

Continuing on with that WebExtension, but with a detour in custom Encoders

https://www.whynotestflight.com/excuses/how-do-custom-encoders-work/

Found the best thing for it was copying and making crazy graphs of some existing encoders in the Apple/GitHub repos. Here's 4

I found the comparison between the two different JSONEncoder implementations particularly interesting.

#Codable, #Encoder, #SwiftLang, #JSON, #JSONEncoder, #URIEncoder

You know how conforming to Codable makes it so any UIView subclass has to implement codable (even if it just is to fatalError() because you only ever plan to create the view in code).

Is there a good #Swift design pattern for creating class hierarchies like that? Where the base class supports and implements a feature, but you don't want subclasses to be forced to provide it?