Merge pull request #654 from DavidCarpus/master
Some grammer/spelling corrections. And one code sample fix
This commit is contained in:
commit
d195e0d185
|
@ -35,6 +35,7 @@ impl Query {
|
|||
You can put data inside the context at the creation of the schema, it's usefull for data that do not change, like a connection pool.
|
||||
|
||||
An instance of how it would be written inside an application:
|
||||
|
||||
```rust
|
||||
let schema = Schema::build(Query::default(), Mutation::default(), EmptySubscription)
|
||||
.data(env_struct)
|
||||
|
@ -45,7 +46,7 @@ An instance of how it would be written inside an application:
|
|||
|
||||
### Request data
|
||||
|
||||
You can put data inside the context at the execution of the request, it's usefull for authentification data for instance.
|
||||
You can put data inside the context at the execution of the request, it's useful for authentication data for instance.
|
||||
|
||||
A little example with a `warp` route:
|
||||
|
||||
|
@ -64,12 +65,11 @@ let graphql_post = warp::post()
|
|||
.data(your_auth_data)
|
||||
.data(something_else)
|
||||
).await;
|
||||
|
||||
|
||||
Ok(async_graphql_warp::Response::from(response))
|
||||
});
|
||||
```
|
||||
|
||||
|
||||
## Headers
|
||||
|
||||
With the Context you can also insert and appends headers.
|
||||
|
@ -87,7 +87,7 @@ impl Query {
|
|||
// If multiple headers with the same key are `inserted` then the most recent
|
||||
// one overwrites the previous. If you want multiple headers for the same key, use
|
||||
// `append_http_header` for subsequent headers
|
||||
let was_in_headers = ctx.insert_http_header("Custom-Header", "Hello World");
|
||||
let was_in_headers = ctx.append_http_header("Custom-Header", "Hello World");
|
||||
|
||||
String::from("Hello world")
|
||||
}
|
||||
|
|
|
@ -1,6 +1,6 @@
|
|||
# SimpleObject
|
||||
|
||||
`SimpleObject` directly maps all the fields of a struct to GraphQL object.
|
||||
`SimpleObject` directly maps all the fields of a struct to GraphQL object.
|
||||
If you don't require automatic mapping of fields, see [Object](define_complex_object.html).
|
||||
|
||||
The example below defines an object `MyObject` which includes the fields `a` and `b`. `c` will be not mapped to GraphQL as it is labelled as `#[graphql(skip)]`
|
||||
|
@ -26,7 +26,7 @@ struct MyObject {
|
|||
Sometimes most of the fields of a GraphQL object simply return the value of the structure member, but a few
|
||||
fields are calculated. In this case, the [Object](define_complex_object.html) macro cannot be used unless you hand-write all the resolvers.
|
||||
|
||||
The `ComplexObject` macro works in conjuction with the `SimpleObject` macro. The `SipmleObject` derive macro defines
|
||||
The `ComplexObject` macro works in conjuction with the `SimpleObject` macro. The `SimpleObject` derive macro defines
|
||||
the non-calculated fields, where as the `ComplexObject` macro let's you write user-defined resolvers for the calculated fields.
|
||||
|
||||
Resolvers added to `ComplexObject` adhere to the same rules as resolvers of [Object](define_complex_object.html).
|
||||
|
@ -42,7 +42,7 @@ struct MyObj {
|
|||
#[ComplexObject]
|
||||
impl MyObj {
|
||||
async fn c(&self) -> i32 {
|
||||
self.a + self.b
|
||||
self.a + self.b
|
||||
}
|
||||
}
|
||||
```
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
# Field Guard
|
||||
|
||||
You can define `guard` to field of an `Object`. This permit to add checks before run the code logic of the field.
|
||||
`Guard` are made of rules that you need to define before. A rule is a structure which implement the trait `Guard`.
|
||||
You can define a `guard` to a field of an `Object`. This permits you to add checks before runing the code logic of the field.
|
||||
`Guard` are made of rules that you need to define before. A rule is a structure which implements the trait `Guard`.
|
||||
|
||||
```rust
|
||||
#[derive(Eq, PartialEq, Copy, Clone)]
|
||||
|
@ -27,15 +27,15 @@ impl Guard for RoleGuard {
|
|||
```
|
||||
|
||||
Once you have defined your rule you can use it in the `guard` field attribute.
|
||||
This attribute support 4 operators to create complex rules :
|
||||
This attribute supports 4 operators to create complex rules :
|
||||
|
||||
- `and` : perform a `and` operation between two rules. (If one rule return an error the `and` operator will return the error. If both rules return a error it's the first one that will be returned).
|
||||
- `and` : perform an `and` operation between two rules. (If one rule returns an error the `and` operator will return the error. If both rules return an error it's the first one that will be returned).
|
||||
|
||||
- `or` : perform a `or` operation between two rules. (If both rules return an error the error returned is the first one)
|
||||
- `or` : performs an `or` operation between two rules. (If both rules return an error the error returned is the first one)
|
||||
|
||||
- `chain` : take a set of rules and run them until one return an error or return `Ok` if all rules pass.
|
||||
- `chain` : takes a set of rules and runs them until one returns an error or it returns `Ok` if all rules pass.
|
||||
|
||||
- `race` : take a set of rules and run them until one return `Ok` if they all fail it return the last error.
|
||||
- `race` : takes a set of rules and runs them until one returns `Ok` if they all fail, it returns the last error.
|
||||
|
||||
```rust
|
||||
#[derive(SimpleObject)]
|
||||
|
@ -66,4 +66,3 @@ struct Query {
|
|||
value5: i32,
|
||||
}
|
||||
```
|
||||
|
||||
|
|
|
@ -1,13 +1,11 @@
|
|||
# Input value validators
|
||||
|
||||
|
||||
Arguments to a query ([InputObject](define_input_object.md)) are called `Input Objects` in GraphQL. If the provided input type does not match for a query, the query will return a type mismatch error. But sometimes we want to provide more restrictions on specific types of values. For example, we might want to require that an argument is a valid email address. `Async-graphql` provides an input validators to solve this problem.
|
||||
Arguments to a query ([InputObject](define_input_object.md)) are called `Input Objects` in GraphQL. If the provided input type does not match for a query, the query will return a type mismatch error. But, sometimes we want to provide more restrictions on specific types of values. For example, we might want to require that an argument is a valid email address. `Async-graphql` provides an input validators to solve this problem.
|
||||
|
||||
An input validator can be combined via `and` and `or` operators.
|
||||
|
||||
The following is an input validator which checks that a `String` is a valid Email or MAC address:
|
||||
|
||||
|
||||
```rust
|
||||
use async_graphql::*;
|
||||
use async_graphql::validators::{Email, MAC};
|
||||
|
|
Loading…
Reference in New Issue