Feat: Add support for custom scalar types [updated] #104
Conversation
Move the GQLResponseParser into the gql library.
Each time a GQL query is made by the client, the response is passed through
ResponseParser.parse() where it is processed.
Configure your own custom scalars as follows:
```
custom_scalars = {
'SomeCustomScalar': <ScalarClass>
}
gql_client = GQLClient(transport=gql_transport,
schema=schema,
custom_scalars=custom_scalars)
gql_client.execute(...)
```
<ScalarClass> should have a .parse_value(value) function
There are a few anti-patterns I have had to include in order to support
some new functionality that we require:
- client.execute now accepts `url` and `headers` as arguments, since we
need to be able to set these on a per request basis. Previously they were
supplied by the transport (which gets set only once at initialization
time).
- As a consequence, the url supplied in to the transport goes unused if a
url is passed in to `execute()`. It is a required field so I have to pass
in a string, but it's not the best.
The tests were copied over from a different repo and so were inconsistent with the Star Wars schema we are using here. This PR should fix the tests (although we are still using a remote schema rather than a local one, so the tests run slowly becuase they need to make a http request each time).
The 'ResponseParser' name was confusing because it was too broad, and we weren't really actually parsing the response. Hopefully this makes it clearer that what we are actually doing it just adding support for custom types.
Stick to the format of having a one line summary followed by more detailed information.
Since we are now merging the headers specified in the transport with the headers specified on a per request basis, we need to make sure the old headers are of type `dict`, a `None` is not sufficient.
GQLServerError maps to errors which are generated on the backend server. I.e. the server responds with a <200 OK> but an "errors" field is included within the response. These are often user facing errors and should be handled as such. GQLSyntaxError maps to cases where either the query or the schema is improperly formatted. This usually indicates a mistake in the code.
Previously we were using Python3.5+ type annotation syntax but this is not backwards compatible so we are removing it.
|
Also why do we need to provide a class with a |
Not sure what was the reasoning behind this but probably it was done in order to keep most of the boilerplate code on its own class so any extra stuff can be added later to extend the type adapter functionality. |
…ustom-scalar-types
|
Some thoughts:
|
Indeed, this should support any kind of leaf types like as Enums or Objects, this PR wanted to bring the old one with the latest features of gql so I didn't bother to add the rest of types to keep the review simple.
Never though about that, maybe we should perform the conversion using the AST and checking each node kind to find the correct and perform the operation on it. For this setp, there is a |
|
The proposition of @KingDarBoja to use the Visitor pattern on the document AST has been implemented in PR #256. Thank again for your work anyway 🚀 |
Updated #33 with latest changes from master. Had to open my own branch as I don't have permission to push to source repo.