Skip to content

Commit 0632942

Browse files
authored
Merge pull request #11 from ma2gedev/fix-typo
Fix typo
2 parents 84ceef5 + 195bbbd commit 0632942

File tree

16 files changed

+28
-28
lines changed

16 files changed

+28
-28
lines changed

content/documentation/master/data-fetching.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -183,7 +183,7 @@ the query is executed. The following section explains more on this.
183183
* ``DataFetchingFieldSelectionSet getSelectionSet()`` - the selection set represents the child fields that have been "selected" under neath the
184184
currently executing field. This can be useful to help look ahead to see what sub field information a client wants. The following section explains more on this.
185185

186-
* ```ExecutionId getExecutionId()`` - each query execution is given a unique id. You can use this perhaps on logs to tag each individual
186+
* ``ExecutionId getExecutionId()`` - each query execution is given a unique id. You can use this perhaps on logs to tag each individual
187187
query.
188188

189189

@@ -223,6 +223,6 @@ The sub fields here of the ``products`` field represent the selection set of tha
223223
so the data fetcher can optimise the data access queries. For example an SQL backed system may be able to use the field sub selection to
224224
only retrieve the columns that have been asked for.
225225

226-
In the example above we have asked for ``selectionLocations`` information and hence we may be able to make an more efficient data access query where
226+
In the example above we have asked for ``sellingLocations`` information and hence we may be able to make an more efficient data access query where
227227
we ask for product information and selling location information at the same time.
228228

content/documentation/master/exceptions.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -28,7 +28,7 @@ These are not graphql errors in execution but rather totally unacceptable condit
2828

2929
- `graphql.execution.UnresolvedTypeException`
3030

31-
is thrown if a graphql.schema.TypeResolver` fails to provide a concrete
31+
is thrown if a `graphql.schema.TypeResolver` fails to provide a concrete
3232
object type given a interface or union type.
3333

3434

@@ -47,7 +47,7 @@ These are not graphql errors in execution but rather totally unacceptable condit
4747
- `graphql.schema.validation.InvalidSchemaException`
4848

4949
is thrown if the schema is not valid when built via
50-
graphql.schema.GraphQLSchema.Builder#build()`
50+
`graphql.schema.GraphQLSchema.Builder#build()`
5151

5252
- `graphql.execution.UnknownOperationException`
5353

content/documentation/master/execution.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -419,7 +419,7 @@ By default the "query" execution strategy is ``graphql.execution.AsyncExecutionS
419419
each field as ``CompleteableFuture`` objects and not care which ones complete first. This strategy allows for the most
420420
performant execution.
421421

422-
The data fetchers invoked can themselves return `CompletionStage`` values and this will create
422+
The data fetchers invoked can themselves return ``CompletionStage`` values and this will create
423423
fully asynchronous behaviour.
424424

425425
So imagine a query as follows

content/documentation/master/scalars.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -69,12 +69,12 @@ We would create a singleton ``graphql.schema.GraphQLScalarType`` instance for th
6969
The real work in any custom scalar implementation is the ``graphql.schema.Coercing`` implementation. This is responsible for 3 functions
7070

7171
* ``parseValue`` - takes a variable input object and converts into the Java runtime representation
72-
* ``parseLiteral`` - takes an AST literal ``graphql.language.Value` as input and converts into the Java runtime representation
72+
* ``parseLiteral`` - takes an AST literal ``graphql.language.Value`` as input and converts into the Java runtime representation
7373
* ``serialize`` - takes a Java object and converts it into the output shape for that scalar
7474

7575
So your custom scalar code has to handle 2 forms of input (parseValue / parseLiteral) and 1 form of output (serialize).
7676

77-
Imagine this query, which uses variables, AST literals and outputs our scalar type ```email``.
77+
Imagine this query, which uses variables, AST literals and outputs our scalar type ``email``.
7878

7979
{{< highlight graphql "linenos=table" >}}
8080
mutation Contact($mainContact: Email!) {

content/documentation/v10/data-fetching.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -183,7 +183,7 @@ the query is executed. The following section explains more on this.
183183
* ``DataFetchingFieldSelectionSet getSelectionSet()`` - the selection set represents the child fields that have been "selected" under neath the
184184
currently executing field. This can be useful to help look ahead to see what sub field information a client wants. The following section explains more on this.
185185

186-
* ```ExecutionId getExecutionId()`` - each query execution is given a unique id. You can use this perhaps on logs to tag each individual
186+
* ``ExecutionId getExecutionId()`` - each query execution is given a unique id. You can use this perhaps on logs to tag each individual
187187
query.
188188

189189

@@ -223,6 +223,6 @@ The sub fields here of the ``products`` field represent the selection set of tha
223223
so the data fetcher can optimise the data access queries. For example an SQL backed system may be able to use the field sub selection to
224224
only retrieve the columns that have been asked for.
225225

226-
In the example above we have asked for ``selectionLocations`` information and hence we may be able to make an more efficient data access query where
226+
In the example above we have asked for ``sellingLocations`` information and hence we may be able to make an more efficient data access query where
227227
we ask for product information and selling location information at the same time.
228228

content/documentation/v10/exceptions.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -28,7 +28,7 @@ These are not graphql errors in execution but rather totally unacceptable condit
2828

2929
- `graphql.execution.UnresolvedTypeException`
3030

31-
is thrown if a graphql.schema.TypeResolver` fails to provide a concrete
31+
is thrown if a `graphql.schema.TypeResolver` fails to provide a concrete
3232
object type given a interface or union type.
3333

3434

@@ -47,7 +47,7 @@ These are not graphql errors in execution but rather totally unacceptable condit
4747
- `graphql.schema.validation.InvalidSchemaException`
4848

4949
is thrown if the schema is not valid when built via
50-
graphql.schema.GraphQLSchema.Builder#build()`
50+
`graphql.schema.GraphQLSchema.Builder#build()`
5151

5252
- `graphql.execution.UnknownOperationException`
5353

content/documentation/v10/execution.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -419,7 +419,7 @@ By default the "query" execution strategy is ``graphql.execution.AsyncExecutionS
419419
each field as ``CompleteableFuture`` objects and not care which ones complete first. This strategy allows for the most
420420
performant execution.
421421

422-
The data fetchers invoked can themselves return `CompletionStage`` values and this will create
422+
The data fetchers invoked can themselves return ``CompletionStage`` values and this will create
423423
fully asynchronous behaviour.
424424

425425
So imagine a query as follows

content/documentation/v10/scalars.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -69,12 +69,12 @@ We would create a singleton ``graphql.schema.GraphQLScalarType`` instance for th
6969
The real work in any custom scalar implementation is the ``graphql.schema.Coercing`` implementation. This is responsible for 3 functions
7070

7171
* ``parseValue`` - takes a variable input object and converts into the Java runtime representation
72-
* ``parseLiteral`` - takes an AST literal ``graphql.language.Value` as input and converts into the Java runtime representation
72+
* ``parseLiteral`` - takes an AST literal ``graphql.language.Value`` as input and converts into the Java runtime representation
7373
* ``serialize`` - takes a Java object and converts it into the output shape for that scalar
7474

7575
So your custom scalar code has to handle 2 forms of input (parseValue / parseLiteral) and 1 form of output (serialize).
7676

77-
Imagine this query, which uses variables, AST literals and outputs our scalar type ```email``.
77+
Imagine this query, which uses variables, AST literals and outputs our scalar type ``email``.
7878

7979
{{< highlight graphql "linenos=table" >}}
8080
mutation Contact($mainContact: Email!) {

content/documentation/v11/data-fetching.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -183,7 +183,7 @@ the query is executed. The following section explains more on this.
183183
* ``DataFetchingFieldSelectionSet getSelectionSet()`` - the selection set represents the child fields that have been "selected" under neath the
184184
currently executing field. This can be useful to help look ahead to see what sub field information a client wants. The following section explains more on this.
185185

186-
* ```ExecutionId getExecutionId()`` - each query execution is given a unique id. You can use this perhaps on logs to tag each individual
186+
* ``ExecutionId getExecutionId()`` - each query execution is given a unique id. You can use this perhaps on logs to tag each individual
187187
query.
188188

189189

@@ -223,6 +223,6 @@ The sub fields here of the ``products`` field represent the selection set of tha
223223
so the data fetcher can optimise the data access queries. For example an SQL backed system may be able to use the field sub selection to
224224
only retrieve the columns that have been asked for.
225225

226-
In the example above we have asked for ``selectionLocations`` information and hence we may be able to make an more efficient data access query where
226+
In the example above we have asked for ``sellingLocations`` information and hence we may be able to make an more efficient data access query where
227227
we ask for product information and selling location information at the same time.
228228

content/documentation/v11/exceptions.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -28,7 +28,7 @@ These are not graphql errors in execution but rather totally unacceptable condit
2828

2929
- `graphql.execution.UnresolvedTypeException`
3030

31-
is thrown if a graphql.schema.TypeResolver` fails to provide a concrete
31+
is thrown if a `graphql.schema.TypeResolver` fails to provide a concrete
3232
object type given a interface or union type.
3333

3434

@@ -47,7 +47,7 @@ These are not graphql errors in execution but rather totally unacceptable condit
4747
- `graphql.schema.validation.InvalidSchemaException`
4848

4949
is thrown if the schema is not valid when built via
50-
graphql.schema.GraphQLSchema.Builder#build()`
50+
`graphql.schema.GraphQLSchema.Builder#build()`
5151

5252
- `graphql.execution.UnknownOperationException`
5353

0 commit comments

Comments
 (0)