[RFC-5] Move query selection to structure initialiser

[maticzav]

API

One of the most common ways for us to construct a query for a particular type is to add a static method selection to a particular structure.

struct Human: Identifiable {
    var id: String
    var name: String
    
    // MARK: - Selection
    
    static let selection = Selection.Human {
        Human(id: try $0.id, name: try $0.name)
    }
}

enum Vehicle {
    case car
    case bus(Int)
    
    // MARK: - Selection
    
    static let selection = Selection.Vehicle {
        let passengers = try $0.passengers()
        let type = try $0.type()
        switch type {
        case .bus:
            return Vehicle.bus(pessengers)
        case .car:
            return Vehicle.car
        }
    }
}

This seemed like a very clean solution and it did the job well. Now as the library evolves it seems better to extract this pattern into a more Swift-native concept. My idea here is that we add a protocol (e.g. Queriable) that requires an initialiser that takes a Field<TypeLock> type as an input and initialised the current type. Once a structure conforms to the Queriable protocol you can use it in the queries.

I think this makes a lot of sense since the new API would highly resemble the decoder API that Swift has built in.

struct Human: Identifiable, Queriable {
    var id: String
    var name: String
    
    // MARK: - Initialiser
    
    init(selection: Fields<Objects.Human>) throws {
        self.id = try selection.id()
        self.name = try selection.name()
    }
}

Syntactic Sugars

I love how we implemented the Selection.Human type alias. They let us have much better IDE integration and I think we should do the same thing with Fields.Human.

struct Human: Identifiable, Queriable {
    var id: String
    var name: String
    
    // MARK: - Initialiser
    
    init(selection: Fields.Human) throws {
        self.id = try selection.id()
        self.name = try selection.name()
    }
}

Legacy

It might seem like we should replace the Selection.Human API entirely in favour of the new initialisers API. I don't think that's a good idea. Instead, we should aim to make Selection.Human by default conform to Queriable and have the two APIs interchangeable.

[Amzd]

Looks good to me.

Maybe name it init(fields:)?

It's possible to do something like:

protocol Queriable {
    associatedtype T
    init(fields: Fields<T>)
}

extension Queriable {
    static var selection: Selection<Self, T> {
        .init(decoder: Self.init(fields:))
    }
}

Which would have the same behaviour as your initial example but you'd write your selection as the init.

Or do you want to change the HTTP methods to accept the Queriable rather than a Selection?

[maticzav]

I had the very same idea!

Regarding having HTTP methods accept Queriable rather than Selection, what do you think? It seems like having a protocol-driven code-base could clear up the internal logic, but we'd also have to rethink some of the patterns in the core.

[Amzd]

I think if we're gonna change the syntax we might as well try to cover this too #9

I've put a bit more investigation in and the main problem that needs addressing to remove mocking is that we throw badpayload when the Field value function is called even though we could already know about the bad payload during decoding. Removing the throw at that function and throwing earlier would make future syntax updates much easier even if we don't remove the mocking code.

[maticzav]

That's interesting! How would you collect selection in such a case? Do you think we could support nonNullOrFail through decoders as well?