-
Notifications
You must be signed in to change notification settings - Fork 426
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Introduce a abstraction for scalar values
Before this possible scalar values where hard coded to be representable in one of the following types: `i32`, `f64`, `String` or `bool`. This restricts what types of custom scalar values could be defined. (For example it was not possible to define a scalar value that represents a `i64` without mapping it to a string (that would be not efficient)) One solution to fix that example above would simply be to change the internal representation to allow it represent a `i64`, but this would only fix the problem for one type (till someone want's to support `i128` for example…). Also this would make juniper not following the graphql standard closely. This commit tries to explore another approach, by making the exact "internal" representation of scalar values swappable (in such a way that a down stream crate could provide it's own representation tailored to their needs). This allows juniper to provide a default type that only contains the types described in the standard whereas other crates could define custom scalars following their needs. To that we need to change several things in the current implementation * Add some traits that abstract the behaviour of such a scalar value representation * Change `Value` and `InputValue` to have a scalar variant (with a generic type) instead of hard coded variants for the standard types. This implies adding a generic parameter to both enums that needs to be added in the whole crate. * Change the parser to allow deciding between different types of scalar values. The problem is basically that the original parser implementation had no way to know whether a parsed integer number is a `i32` or a `i64` for example. To fix this we added some knowlege from the existing schema to the parser. * Fix some macros and derives to follow the new behaviour This also contains a unrelated change about the way `juniper_codegen` resolves items from juniper. In detail the `_internal` flag is removed the the resolution is replaced by an macro. This is a drive by change because I was annoyed of adding new items to that list.
- Loading branch information
Showing
87 changed files
with
6,003 additions
and
3,308 deletions.
There are no files selected for viewing
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.