Apollo-ios: Optional errors array in GraphQLResult

[wnagrodzki]

Hi :)

Current GraphQLResult's API provides us with optional errors array.

public struct GraphQLResult<Data> {

    /// A list of errors, or `nil` if the operation completed without encountering any errors.
    public let errors: [Apollo.GraphQLError]?
}

This seems consistent with the documentation:

The errors entry in the response is a non‐empty list of errors, where each error is a map.
If no errors were encountered during the requested operation, the errors entry should not be present in the result.

Looking from the client perspective: Is there a difference between nil and empty array []?

What is your opinion of collapsing those two cases into one, empty array?

public struct GraphQLResult<Data> {

    /// List of errors encountered during the operation.
    public let errors: [Apollo.GraphQLError]
}

[designatednerd]

I definitely see where you're coming from, but I don't think a non-nullable array of errors would work for several reasons:

• [the big one] It'd conflict with the GraphQL philosophy of "Everything is nullable unless you explicitly specify that it's not".
• I'd find it fairly odd if data was nullable but errors was not, even though both can be returned as a null value from the server.
• It won't be totally straightforward to maintain this once we switch to Codable parsing. When Codable has a property with a null value, you'd have to manually transform that into an empty array.

Does that answer your question?

[wnagrodzki]

Yes, it does. I can see the benefits of the approach you took.

I seems I got this expectation at back of my head that API would be tailored to reflect constraints from documentation like:

If the data entry in the response is not present, the errors entry in the response must not be empty. It must contain at least one error.

You helped me to see it from another point of view, thanks.

[designatednerd]

Cool - mind if we close this out?

[wnagrodzki]

Sure