Current limitations in GraphQLError

[apollographql]

Current limitations in GraphQLError

[martijnwalraven]

(Responding here instead of on the PR for context.)

Thanks for bringing this up! I agree adding locations to GraphQLError makes sense.

I also see why custom error keys would be useful, but forcing users to specify a custom error type seems like a very heavyweight solution. Swift doesn't support default type arguments, so your PR would force you to always fully specify the type parameters of GraphQLResult everywhere, e.g. for every fetch.

Instead of custom error types, an alternative might be to modify GraphQLError to allow storing additional keys as a dictionary. By default, it would make them available untyped through a subscript. And then you could add typed accessors in your own app as an extension on GraphQLError:

extension GraphQLError {
  var userMessage: String? {
    return self["userMessage"] as? String
  }
}

How does that sound?

[martijnwalraven]

I implemented the solution we discussed as part of f77286f.

[sibljon]

Good call on the light-weight solution you've proposed -- it seems like it'll be better for most consumers of this library. I hadn't noticed the inconvenience since I only use fetch and perform once in a wrapper, but you're right that it's there for those who don't wrap.

I'll go ahead and close #40. Implementing this is not something I've got steam for right now, but perhaps in the future.

[benrom]

@martijnwalraven I'm implementing the GraphQLError extension you suggested above, xcode complains on the self[ bit with:

Type GraphQLErrorhas no subscript members

Is there something I'm missing?

[martijnwalraven]

@benrom: This was only recently added and is not not in the patch 0.4.3 version yet.