Narrowly Scoped equality on SelectionSet models about apollo-ios HOT 1 OPEN

Thanks for the writeup. I think I have a differing opinion on the ambiguity you mentioned.

I think it's mostly a divergence in how we're thinking about these models. One perspective comes from a GraphQL perspective of "These fragments come from different underlying data, so they're not equal", but our perspective is to look at these things purely as Swift data structures. In our view the source of these structures is an implementation detail. It could be GraphQL or, as in our case at Stitch Fix, it could be fixtures constructed using initializers during a unit test. If we view your taxonomy fragment example in the abstract, it boils down to something like:

struct TaxonomyFragment: Equatable {
    var species: String { /* ... */ }
    var genus: String { /* ... */ }

    init(species: String, genus: String) {
        /* ...  */
    }
}

Purely from a Swift API contract perspective, there really is no ambiguity. Having two of these structures be unequal because of hidden influences breaks the spirit of the Equatable contract. The only way the other fields become an issue is if we let implementation details leak out of the abstraction, which is essentially what is happening today. The current Equatable conformance for fragments is closer to an identity check (===), which I think is separate from the question of whether two TaxonomyFragments are equivalent.

I suggest that a breaking change here is appropriate because I think the current behavior is unexpected. Requiring a separate custom "actually equivalent" function is inconvenient because it renders many built in standard Swift library functions subtly broken with no warning. Just to name a few:

• Set
• Publisher.removeDuplicates()
• Array.contains(Self.Element) -> Bool
• Array.firstIndex(of element: Self.Element) -> Int?
• and many more

Our Plan

Since the SelectionSet protocol declares itself to be Equatable and the subtle unreliability of that check, we decided that this was going to be a source for new bugs and/or unit test difficulties. Our solution is going to be extending our catalog of post-processing Sourcery stencils we use to add to the generated code to add custom == operator overloads for all SelectionSets that strictly check just the logical fields at each level. This would result in something like the following for the taxonomy example above.

public func ==(lhs: TaxonomyFragment, rhs: TaxonomyFragment) -> Bool {
    lhs.species == rhs.species &&
    lhs.genus == rhs.genus
}

This is a bit inconvenient and time-consuming, and you're right that this will add to our build time and binary size, but we're prioritizing fewer subtle bugs and developer experience over conciseness in this case.

Update:

After benchmarking the compile-time difference with our auto-generated == overloads (a ~30-40s increase in build times) and after scoping the feasibility of doing equality checks at runtime using already-present schema metadata, we've decided to go the runtime route by traversing the DataDict structure itself and using each models __selections array as a guide for informing how to compare various values at each level. After a couple bumpy patches we have everything building and passing unit tests with some additional unit tests thrown in for our custom implementation.

It does seem very possible for this to be built-in to the standard Apollo library, and I encourage you to consider doing so.

from apollo-ios.