Handling unknown enum cases

Even though they are sometimes overused, enums are still a great tool. Thanks to Codable they can easily be decoded from JSON sent by your backend.

This is great until you need to add a new case to the enum. Then you have to either deal with versioning your API or you need to tell your users to update the app. In some cases you have no choice, but in other cases it would be fine to just ignore the new value and fall back to some default behavior.

Here are a few ways I used to realize such a scenario:

RawRepresentable struct

The simplest way would be to replace enums with a RawRepresentable struct:

struct ItemType: RawRepresentable, Codable {
    var rawValue: String
    
    static let house = ItemType(rawValue: "house")
    static let tree = ItemType(rawValue: "tree")
}
Code language: JavaScript (javascript)

In code this can be used just like an enum would, you’d only have to add a default case to every switch statement.

This can lead to situations where a different subset of those cases is handled in different places. Sometimes that’s fine, but in other cases you want to ensure to handle all known cases everywhere. So you need an actual enum in order for the compiler to be able to do exhaustiveness checks.

Enum with “Unknown” case

To do this we simply can manually implement the decoding and map unknown values to a default case:

enum ItemType: String, Codable {
    case house
    case tree
    case unknown

    init(from decoder: Decoder) throws {
        let container = try decoder.singleValueContainer()
        let string = try container.decode(String.self)
        switch string {
        case "house": self = .house
        case "tree": self = .tree
        default: self = .unknown
        }
    }
}
Code language: JavaScript (javascript)

Implementing this for many enums becomes pretty boring. Luckily we can share the implementation between all enums by writing a protocol with a default implementation:

protocol UnknownDecodable: Decodable, RawRepresentable {
    static var unknown: Self { get }
}

extension UnknownDecodable where RawValue: Decodable {
    init(from decoder: Decoder) throws {
        let container = try decoder.singleValueContainer()
        let raw = try container.decode(RawValue.self)
        self = Self(rawValue: raw) ?? .unknown
    }
}Code language: JavaScript (javascript)

Using this we can define our enum like we would normally and get that behavior for free by just conforming to the UnknownDecodable protocol. Note that our enum case unknown can fulfill the protocol requirement of static var unknown: Self:

enum ItemType: String, Codable, UnknownDecodable {
    case house
    case tree
    case unknown
}Code language: JavaScript (javascript)

Decoding unknown cases as nil

A final solution I sometimes find useful is decoding the enum as optional and mapping unknown values to nil

This is easy to do if we manually implement decoding for the struct that contains this enum. But this would lead to a lot of (possibly repeated) boilerplate code we don’t like to write. Instead we can use a property wrapper:

@propertyWrapper
struct DecodeUnknownAsNil<Enum: RawRepresentable> where Enum.RawValue: Codable {
    var wrappedValue: Enum?
}

extension DecodeUnknownAsNil : Codable {
    init(from decoder: Decoder) throws {
        let container = try decoder.singleValueContainer()
        let raw = try container.decode(Enum.RawValue.self)
        wrappedValue = Enum(rawValue: raw)
    }

    func encode(to encoder: Encoder) throws {
        var container = encoder.singleValueContainer()
        try container.encode(wrappedValue?.rawValue)
    }
}

extension KeyedDecodingContainer {
    func decode<Enum>(_ type: DecodeUnknownAsNil<Enum>.Type, forKey key: Key) throws -> DecodeUnknownAsNil<Enum> {
        return try decodeIfPresent(type, forKey: key) ?? .init(wrappedValue: nil)
    }
}

extension DecodeUnknownAsNil: Equatable where Enum: Equatable {}
extension DecodeUnknownAsNil: Hashable where Enum: Hashable {}
Code language: JavaScript (javascript)

The extension on KeyedDecodingContainer is necessary to handle missing or null values in the JSON.

When to use which

I choose the RawRepresentable struct when I don’t need to make a decision based on that value. This could be for looking up some resource or other values in a dictionary.

The DecodeUnknownAsNil property wrapper is great if the enum value is optional anyways and you can handle the unknown case just as if there was no value at all.

For most cases I would chose the UnknownDecodable protocol though. If I make my property optional I can distinguish between no value and an unknown value. And if the property is not optional I know the decoding will fail so I can catch bugs on the server side where required properties are missing.

Enum or struct?

I often see a pattern where there is an enum with a bunch of computed properties that return a different value for each case. In the rest of the code base then only those properties are used. Something like this:

enum Style {
    case headline
    case bodyText
    case emphasis
    
    var isBold: Boolean {
        switch self {
            case .headLine, .emphasis: return true
            case .bodyText: return false
        }
    }
    
    var fontSize: CGFloat {
        switch self {
            case .headline: return 20
            case .bodyText, .emphasis: return 16
        }
    }
}Code language: PHP (php)

This works, but quite often can be improved by using a struct instead of an enum. Define a struct which contains all your computed properties as stored properties and the define a global constant of this for each enum case:

struct Style {
    var isBold: Bool
    var fontSize: CGFloat
    
    static let headline = Style(isBold: true, fontSize: 20)
    static let bodyText = Style(isBold: false, fontSize: 16)
    static let emphasis = Style(isBold: true, fontSize: 16)
}Code language: JavaScript (javascript)

This requires less code, it is easier to see and change the values for each case and you can add more cases without having to change the source code of the enum definition.

This doesn’t work in every case though. Better stick to an enum if the identity of the cases is important, for example for control flow. Another issue is (JSON) decoding – the struct would require all the properties in the data.

New attributed strings

Finally we are going to get attributed strings as a native Swift value type. So lets see how we can update the example of my last article about attributed strings:

let string = "Name (whatever)"

var attributed = AttributedString(string)
let nameEnd = attributed.range(of: " (")?.lowerBound ?? attributed.endIndex

attributed[..<nameEnd].font = .body.bold()Code language: Swift (swift)

Pretty neat. No more NSRange to deal with, and we can access the font attribute directly as a typed property. No more dealing with attribute values as Any.

Of course we still want to separate the presentation from the meaning of our strings. So we can take our semantic enum from last time. We need to define our attribute key again, but this time as a type conforming to the AttributedStringKey protocol. This requires a type for our value and a name:

enum Semantic: Hashable {
    case name
}

enum SemanticAttributeKey: AttributedStringKey {
    static let name = "semantic"
    typealias Value = Semantic
}Code language: Swift (swift)

Note that all the requirements from this protocol are static, so its best to define this as an otherwise empty enum so we cannot create an instance of that type, which is never needed.

Next we create our attributed string and find the range we want to highlight. No need for NSRange any more. Using a subscript we can then assign our name attribute to the part of our string we want to highlight in a type-safe way:

attributed[..<nameEnd][SemanticAttributeKey.self] = .nameCode language: Swift (swift)

To display the string we can simply replace our semantic attribute with a given font attribute. For this we prepare an attribute container with our name attribute and another one with the font attribute as an replacement. Finally we create our string to display using the replacingAttributes(_:with:) method:

var nameContainer = AttributeContainer()
nameContainer[SemanticAttributeKey.self] = .name

let boldContainer = AttributeContainer.font(.body.bold())

let displayString = attributed.replacingAttributes(nameContainer, with: boldContainer)Code language: Swift (swift)

Would be nice to directly have a property for our semantic attribute, just as .font provided by Apple. We could define a bunch of extensions on AttributedString, AttributedSubstring, AttributeContainer and so on. But thanks to @dynamicMemberLookup and key paths there is an easier way.

First we need to define an attribute scope. That is a simple struct conforming to the AttributeScope protocol inside an extension of AttributeScopes. There we also need to define a property that returns the type of our scope. Inside of our scope we simply add a let property for each of our attribute keys.

We can even move our attribute key definitions inside the scope, as we won’t have to use the type name in subscripts any more.

Finally we define an extension on AttributeDynamicLookup which provides a dynamicMember subscript for a key path from our scope to any AttributedStringKey.

extension AttributeScopes {
    var myApp: MyAppAttributes.Type { MyAppAttributes.self }

    struct MyAppAttributes: AttributeScope {
        let semantic: SemanticAttributeKey
    }
}

extension AttributeDynamicLookup {
    subscript<T: AttributedStringKey>(dynamicMember keyPath: KeyPath<AttributeScopes.MyAppAttributes, T>) -> T {
        self[T.self]
    }
}Code language: Swift (swift)

Note that AttributeDynamicLookup is an empty enum, so our subscript can never actually be called. Sadly this leads to some warnings about calling never-returning functions, at least with the current (at the time of writing this) Xcode 13 beta 3.

With that in place we can directly access .semantic on attributed strings or our attribute containers:

attributed[..<nameEnd].semantic = .name

attributed.replaceAttributes(
    AttributeContainer().semantic(.name), 
    with: AttributeContainer().font(.body.bold())
)Code language: Swift (swift)

If we have multiple semantic attributes we need to replace for display we don’t want to call replaceAttributes or replacingAttributes for each one to avoid unneccessary copies.

If we only need to set a single attribute as a replacement we can use transformingAttributes:

let displayString = attributed.transformingAttributes(\.semantic) { semantic in
    if semantic.value == .name {
        semantic.replace(with: \.font, value: .body.bold())
    }
}Code language: Swift (swift)

If we want to replace each semantic attribute with a set of different attributes (just as the convenience initializer from last time) we again need to write a custom method that loops through the attributes and sets the new attributes:

extension AttributedString {
    func replaceAttributes<T: AttributedStringKey>(_ keyPath: KeyPath<AttributeDynamicLookup, T>, replacements: [T.Value: AttributeContainer], default defaultContainer: AttributeContainer? = nil) -> AttributedString {

        var result = self
        for (value, range) in runs[keyPath] {
            if let value = value, let attributes = replacements[value] ?? defaultContainer {
                result[range].setAttributes(attributes)
            }
        }

        return result
    }
}

let display = attributed.replaceAttributes(
    \.semantic, 
    replacements: [
        .name: AttributeContainer().font(.body.bold())
    ]
)Code language: Swift (swift)

Of course this only scratches the surface. There is a ton more that AttributedString can do. For me the most interesting part probably is the integrated markdown support. Just watch the What’s New in Foundation talk from WWDC 2021.

Attributed Strings

I had to take a string like “Name (whatever)” and display it in a label. The Name part should be bold, and anything in parentheses should use the regular font.

Pretty simple, I just put the string in a NSAttributedString, find the opening parenthesis and add a bold font attribute to everything up to it. If I find no parenthesis I just bold the whole string:

let attributed = NSMutableAttributedString(string: string)
let boldRange = NSRange(string.startIndex ..< (string.range(of: " (")?.lowerBound ?? string.endIndex), in: string)
attributed.addAttributes([.font: UIFont.systemFont(ofSize: 12, weight: .bold)], range: boldRange)Code language: Swift (swift)

But where should I put this code? The part that specifies the font and other presentation specific things should belong to the view layer. Especially since it has to import UIKit to get UIFont. But parsing the string should go in the model layer. In other views I might want to display that string in a different way, so it makes sense to parse it once.

In this case I could split the string and store both parts separately. Another option is to store the range of the name in addition to the whole string. Both approaches are not very scalable. Once I have multiple ranges to highlight this gets too complicated. What I need is a data structure that can assign values to ranges in a string. There are tons of options how to implement this. But luckily I don’t have to since Foundation provides such a thing: NSAttributedString.

First I define a key for a custom attribute and a type for that attribute:

extension NSAttributedString.Key {
    static let semantic = NSAttributedString.Key(rawValue: "de.5sw.semantic")
}

enum Semantic: Hashable {
    case name
}Code language: Swift (swift)

Then I parse the string and add the custom semantic attribute:

let attributed = NSMutableAttributedString(string: string)
let nameRange = NSRange(string.startIndex ..< (string.range(of: " (")?.lowerBound ?? string.endIndex), in: string)
attributed.addAttributes([.semantic: Semantic.name], range: nameRange)Code language: Swift (swift)

The code is basically the same as before, but instead of adding the font attribute I add a custom attribute that specifies the meaning of this part of text.

In the view layer I then enumerate all the ranges with the semantic attribute and add the expected formatting:

let displayString = NSMutableAttributedString(attributedString: model.parsedString)
displayString.beginEditing()
displayString.enumerateAttribute(.semantic, in: NSRange(location: 0, length: displayString.length), options: .longestEffectiveRangeNotRequired) { value, range, _ in
    if let semantic = value as? Semantic, semantic == Semantic.name {
        displayString.setAttributes([.font: UIFont.systemFont(ofSize: 12, weight: .bold)], range: range)
    } else {
        displayString.removeAttribute(.semantic, range: range)
    }
}
displayString.endEditing()Code language: Swift (swift)

I like this code, now I have a clear separation between the meaning of my data and the way it should be presented.

And since I don’t want to repeat this everywhere I need to style an attributed string I encapsulated this in a handy little extension that uses a dictionary to map my custom attribute to actual styles:

extension NSAttributedString {
    convenience init<T>(attributedString: NSAttributedString, key: NSAttributedString.Key, attributes: [T: [NSAttributedString.Key: Any]], default: [NSAttributedString.Key: Any]? = nil) {

        let copy = NSMutableAttributedString(attributedString: attributedString)
        copy.beginEditing()
        copy.enumerateAttribute(key, in: NSRange(location: 0, length: copy.length), options: .longestEffectiveRangeNotRequired) { attribute, range, _ in
            if let value = attribute as? T, let newAttributes = attributes[value] ?? `default` {
                copy.setAttributes(newAttributes, range: range)
            } else {
                copy.removeAttribute(key, range: range)
            }
        }
        copy.endEditing()

        self.init(attributedString: copy)
    }
}Code language: Swift (swift)

Factories and Protocol Composition DI

Especially on iOS it’s often necessary to create new objects like new view controllers or such things. This often cannot be avoided. This usually is solved by having the object that creates new objects also require all the dependencies of the objects it wants to create. This of course is not a great thing as changes in one class can ripple through the whole project. The protocol composition approach solves this by having the flow controllers take the whole AppDependency object so they can pass it on.

This solves the problem of having to change some classes when the dependencies of others changes. But it still is bad for testing as you can’t be sure which dependencies are actually needed, and you have no way to influence which class is instantiated. A common solution to this is injecting factory objects that hold all the necessary resources. This of course can result in rather verbose code if a whole new type is created. Luckily closures can also take the role of those factories.

While implementing this I realized that an extra object is not even necessary with the protocol composition DI. The AppDependency object itself can take the role of the factory:

protocol MakesSomething {
 func makeSomething() -> Something
}

extension AppDependency: MakesSomething {
 func makeSomething() -> Something {
 return Something(dependencies: self)
 }
}Code language: PHP (php)

That code is not so bad and we can avoid having dependencies on unneeded objects which is good for testing. Usage is like any other dependency:

class MyClass {
 typealias Dependencies = MakesSomething & HasOtherThing
 let dependencies: Dependencies
 
 init(dependencies: Dependencies) {
 self.dependencies = dependencies
 }
 
 func doWork() {
 let something = dependencies.makeSomething()
 something.doWhateverItIsSomethingDoes()
 }
}Code language: JavaScript (javascript)

Protocol Composition and Dependency Injection

I recently read the article “Using protocol compositon for dependency injection” by Krzysztof Zabłocki. I found this to be a rather interesting technique for doing DI, but when trying to implement it I found it somewhat limited:

  • It doesn’t really handle dependencies that have dependencies themselves.
  • No support for lazy instantiation, everything needs to be instantiated up front.

Lets look at simple and pretty common example of the object graph I wanted to create:

  • A view controller at the leaf level, which needs
  • An object that provides business logic (like the Interactor from the VIPER pattern), which needs
  • the data store (a NSPersistentContainer in my case).

This can be translated pretty easily to this pattern:

protocol HasCoreData {
  var coreData: NSPersistentContainer { get }
}

protocol HasListInteractor {
  var listInteractor: ListInteractor { get }
}

struct AppDependencies: HasCoreData, HasListInteractor {
  let coreData: NSPersistentContainer
  let listInteractor: ListInteractor
}

final class ListViewController: UIViewController {
  typealias Dependencies = HasListInteractor
  let dependencies: Dependencies

  init(dependencies: Dependencies) {
    self.dependencies = dependencies)
    // ...
  }
}

final class ListInteractor {
  typealias Dependencies = HasCoreData
  let dependencies: Dependencies

  init(dependencies: Dependencies) {
    self.dependencies = dependencies)
    // ...
  }
}

This all works fine until I try to fill in my AppDependencies struct – to create it I need an instance of my ListInteractor, and to create that I need the AppDependencies struct. So this is not going to work.

Instead I could create a second struct that only implements HasCoreData and use that to initialise the ListInteractor. This approach will work, but will quickly become messy and as hard to refactor as passing every dependency separately. It also won’t address the point of avoiding eager initialisation.

But there is a simple solution that addresses both problems:

final class AppDependencies: HasCoreData, HasListInteractor {
  lazy var coreData: NSPersistentContainer = NSPersistentContainer(name: "Whatever")
  lazy var listInteractor: ListInteractor = ListInteractor(dependencies: self)
}

By making the AppDependencies a class instead of a struct we can use lazy properties to fulfil the protocol requirements. That way we can’t get into the catch-22 situation I described and we get lazy instantiation for free.

Of course there are some other drawbacks to consider:

  • Cyclic dependencies will cause infinite recursion
  • Objects are created lazily, so if you need eager instantiation of some class you need to manually call the getter