- make GraphQLUnion trait generic over ScalarValue
- generate generic over ScalarValue impls of GraphQLUnion trait
- add codegen tests with a custom ScalarValue for union macros
- reimplement #[derive(GraphQLUnion)] macro to support:
- both structs and enums
- generics in type definition
- multiple #[graphql] attributes
- external resolver functions
- remove From trait impls generation for enum variants
- reimplement #[graphql_union] macro to support:
- traits
- generics in trait definition
- multiple attributes
- external resolver functions
- GraphQLType implemetation for a raw trait object
- GraphQLTypeAsync implemetation (#549)
- add marker::GraphQLUnion trait
- rewrite "2.5 Unions" section in Book (Juniper user documentation)
- rewrite `codegen` and `codegen_fail` integration tests for GraphQL unions
Additionally:
- re-export `futures` crate in `juniper` for convenient reuse in the generated code without requiring library user to provide `futures` crate by himself (#663)
- use unit type () as default context for EmptyMutation and EmptySubscriptions
- relax Sized trait bound on some GraphQLType and GraphQLTypeAsync definitions, implementations and usages
* Implemented most test cases from the specification
* Unified error handling for all generators
- Removed proc-macro-error -> not required -> use syn::Error
- Everything below lib.rs uses proc_macro2::TokenStream
instead of proc_macro::TokenStream
- Replaced error handling in attribute parsers
* WIP better error messages for *all* macros
* Refactored GraphQLInputObject and minor tweaks
- removed support for Scalar within a string ("DefaultScalarValue")
- removed unraw function and replaced it with the built-in one
- added error messages and return types for all functions within utils
- added more constraints to fulfill the GraphQL spec
* Fixed test-cases which are not compliant with the specification
* Removed unused function
* Added constrains, updated error messages, added marker
* Added argument rename within impl_graphql and fixed `__` tests
* Formatted and cleanup
* Added GraphQLTypeAsync for input object
* Moved codegen tests to separate module
Nightly and stable produce different outputs, thus only test nightly.
* Added IsInputType/IsOutputType traits for type checking
Co-authored-by: Christian Legnitto <LegNeato@users.noreply.github.com>
Fixes#571
Signed-off-by: andrisak <andrisak@gmail.com>
* Replaced the old macro with the new proc macro.
Updated documentation.
Signed-off-by: andrisak <andrisak@gmail.com>
Co-authored-by: Christian Legnitto <LegNeato@users.noreply.github.com>
* Updated implementation of derive enum
- allows context specification
- allows scalar specification
- shares code with derive object
* Added this feature to CHANGELOG
* Added matrix with supported macro attributes for enums
* Added case which checks for custom context
* GraphQLUnion now can use a different context per variant
* Moved context switch test for union into right folder
* Sync resolve expression has the same form as the other impls
* Disabled custom scalar on GraphQLEnum
* Fixed CHANGELOG
* Fixed support matrix of GraphQLEnum in the book
- scalar not supported!
- skip not supported!
* Added test case for "noasync" derive attribute
* Disallowed generics and lifetimes on GraphQLEnum
* Added error message for duplicate naming
* Added error message for empty variant
* Implemented device macro for GraphQLUnion's
* Updated PR link in CHNAGELOG
* Disabled documentation on enumeration fields
* Disabled skip on fields
* Changed implementation for std::convert::Into since skip is not possible
* Added documentation for GraphQLUnion
* Added tests for GraphQLUnion
* Fixed typos in error messages (as suggested by review)
* Fixed failing documentation example
* Utilized `resolver_code` in `util::GraphQLTypeDefinitionField`.
Simplifies code and provides the idea of using
`util::GraphQLTypeDefinitionField` for different types than objects.
* Removed wrong statement about skip annotation in docs.
Co-authored-by: Christian Legnitto <LegNeato@users.noreply.github.com>
Fixes https://github.com/graphql-rust/juniper/issues/534.
I am not sure if the best way is to have folks bring their own futures for the
derives / macros or to pull it in as a dep explicitly like I have done here.
Because people are filing issues, we will do it this way and see what other issues arise.
The trait was introduced while introducing generic scalars, but is not
actually required or useful. It's functionality is fully covered by
methods on the `ScalarValue` trait.
It also forced a lof of for<'a> ScalarRefValue bounds all over the code,
complicating signatures a lot.
It is completely removed now.
* feat: Raw identifier support in object macro
This commit implements raw identifier (`r#name`) support
for field names (methods) and arguments in the `object` proc macro.
Eg:
```rust
impl T {
fn r#type(r#trait: String) -> bool {}
}
```
* Rebase onto master
* Fix merge [skip ci]
This commit implements raw identifier (`r#name`) support
for field names (methods) and arguments in the `object` proc macro.
Eg:
```rust
impl T {
fn r#type(r#trait: String) -> bool {}
}
```
This commit implements a newtype style custom derive
for scalars via `#[derive(GraphQLScalarValue)]`, which now
supports both deriving a base enum scalar type and newtypes.
For newtypes, the `#[graphql(transparent)]` attribute is
required.
This commit:
* implements the derive
* adds integration tests
* updates the book
This commit implements a new proc macro `impl_object` that replaces
the old graphql_object! macro.
The code shares a lot of similarities with the GraphQLObject
custom derive, so the code was unified to handle both
more generically.
Also, doc comment processing was standardized and improved.
Currently, custom derives inside the main juniper crate are supported by
an ugly hack using the __juniper_use_everything macro.
This commit adds new custom derive variants that are for
main juniper crate internal use only (GraphQL{Enum,InputObject}Internal.
All custom derives inside the juniper crate are refactored to use the
new '*Internal' derives.
This allows us to
* remove the use_everything macro,
* simplify the generated code for custom derives
* support the Rust 2018 edition
Partially fixes https://github.com/graphql-rust/juniper/issues/248.
* Install `cargo-release`. (currently need a patched one with https://github.com/sunng87/cargo-release/pull/74)
* Run `cargo make release-dry-run` to do a dry run of a release
* Run `cargo make release` to do a minor versioned release of every crate
* Run `cargo make release-patch` to do a patch release of every crate
To only release one crate:
* Change directories into the desired crate
* Point `cargo-make` to the workspace-level Makefile when running a command. For example, `cargo make --makefile ../Makefile.toml release-dry-run`.
From the workspace root, run `cargo
* Update object/iface macro with doc/deprecated attrs for fields
* Use the note from `#[deprecated]` by default in derived GraphQLType
* Update to support multiline raw-docstring format
* Support bare deprecated attribute
* Update arguments to support #[doc] for parity with previous ` as ` syntax
Introduce an abstraction for scalar values
Before this change, possible scalar values were hard coded to be representable
by one of the following types: `i32`, `f64`, `String` or `bool`. This
restricts the types of custom scalar values that can be defined. For
example, it was not possible to define a scalar value that represents an
`i64` without mapping it to a string (which would be inefficient).
One solution to fix the example above would simply be to change the
internal representation to allow it to represent an `i64`, but this would
only fix the problem for one type (until someone wants to support
`i128` for example). Also this would make juniper not follow the
GraphQL standard closely.
This commit takes another approach, by making the exact "internal"
representation of scalar values swappable (in such a way that a downstream crate could provide its 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 for their needs.
To accomplish this we need to change several things in the current implementation:
* Add some traits that abstract the behavior 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 knowledge
of the existing schema to the parser.
* Fix some macros and derives to follow the new behavior.
This commit also contains an unrelated change about the way `juniper_codegen`
resolves items from `juniper`. The `_internal` flag is removed and
the resolution is replaced by a macro.
The scalar parsing strategy is as follows:
* Pass optional type information all the way down in the parser. If a
field/type/… does note exist, just do not pass down the type
information.
* The lexer now distinguishes between several fundamental scalar types (`String`, `Float`, `Int`). It does not try to actually parse those values, instead it just annotates them that this is a floating point number, an integer number, or a string value, etc.
* If type information exists while parsing a scalar value, try the following:
1. Try parsing the value using that type information.
2. If that fails try parsing the value using the inferred type information from the lexer.
* If no type information exists, try parsing the scalar value using the inferred type from the lexer,
All macros support the introduced scalar value abstraction. It is now possible to specify if a certain implementation should be based on a specific scalar value representation or be generic about the exact representation. All macros now default to the `DefaultScalarValue` type provided by
`juniper` if no scalar value representation is specified. This is done with usability and backwards compatibility in mind.
Finally, we allow specifying the scalar value representations via an attribute
(`#[graphql(scalar = "Type")]`). A default generic implementation
is provided.
* Bump` juniper`, `juniper_codegen`, and `juniper_tests` versions.
* Bump integration crate requirements to include 0.10.0. `juniper_iron` gets a semver breaking version as it has a breaking change but `juniper_iron` does not.
* Move `juniper_rocket` changelog into one file. This aligns with `juniper_iron` and will be easier
to automate in the future.
* Let `juniper_warp` and `juniper_hyper` use `0.9.x` versions of Juniper. They don't rely on anything in 0.10.0 so don't require it.
Fields can now be skipped with the `#[graphql(skip)]` annotation. Note this
doesn't really make sense for GraphQLInputObjects so this isn't supported there.
Fixes https://github.com/graphql-rust/juniper/issues/220.
If a field has a description, we properly generate a meta field definition like:
```rust
{
let field = registry.field::<String>("id", &());
let field = field.description("Whatever");
field
}
```
If a field does not have a description, we were generating something like:
```rust
{
let field = registry.field::<String>("id", &());
let field = field; // <--- Note not needed
field
}
```
This of course works (and was likely optimized out by the compiler), but bloats
generated code for no benefit.
This change merely makes the second case generate:
```rust
{
let field = registry.field::<String>("id", &());
field
}
```
Fixes https://github.com/graphql-rust/juniper/issues/185.
Introduce a to_upper_snake_case() helper to properly convert enum names
to GraphQL compatible names.
Previously, "SomeEnum" would be converted to "SOMEENUM" and not
"SOME_ENUM".
* Extend derive for enums to allow deriving inside the juniper crate
itself. Note: this is a rather ugly hack right now, FIXME is in the
code
* Remove the graphql_enum! macro and replace all internal use with
derive
* Refactor introspection tests to use derive
Description attribute was available, but not actually used for derive
Object, InputObject and enum and the fields on input object.
Description is now properly set in each of those cases.
Also, tests for all three derives now properly verify the meta
information (name and description) for the derived GraphQLType.
This adds a simple derive for objects that implements GraphQLType for
structs which do not require any manual resolvers.
This could be extended in the future to provide a custom resolver
function via an attribute.
Also adds an integration test.
