You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: doc/mutations/README.md
+3-3
Original file line number
Diff line number
Diff line change
@@ -29,7 +29,7 @@ input ArticleInput {
29
29
}
30
30
```
31
31
32
-
And now in our `.exntends.graphqls` file we will extend the Mutation type to add our new mutation. This is so that in the future other modules can also themselves extend this type with new mutations keeping things organized.
32
+
And now in our `.extends.graphqls` file we will extend the Mutation type to add our new mutation. This is so that in the future other modules can also themselves extend this type with new mutations keeping things organized.
33
33
34
34
```
35
35
extend type Mutation {
@@ -137,10 +137,10 @@ class CreateArticle extends DataProducerPluginBase implements ContainerFactoryPl
137
137
}
138
138
```
139
139
140
-
### Important note
140
+
### Important note
141
141
142
142
One thing to notice when creating mutations like this is that Access checking needs to be done in the mutation, for queries this usually is done in the
143
-
data producer directly (e.g. `entity_load` has access checking built-in) but because we are programatically creating
143
+
data producer directly (e.g. `entity_load` has access checking built-in) but because we are programmatically creating
144
144
things we need to check the user actually has access to do the operation.
Copy file name to clipboardexpand all lines: doc/mutations/validations.md
+3-3
Original file line number
Diff line number
Diff line change
@@ -49,7 +49,7 @@ We define a Violation scalar which will just hold the error messages that will b
49
49
50
50
## Create the ArticleResponse class
51
51
52
-
Because we need adition content inside our Response we make a class that implements the module's ResponseInterface. Inside it will have a `article` property (like we saw before). This will be added in the `src/Wrappers/Response` folder and we will call it `ArticleResponse.php`
52
+
Because we need additional content inside our Response we make a class that implements the module's ResponseInterface. Inside it will have a `article` property (like we saw before). This will be added in the `src/Wrappers/Response` folder and we will call it `ArticleResponse.php`
53
53
54
54
```php
55
55
@@ -207,7 +207,7 @@ We have added a new type that is returned `$response` where we call the `setArti
207
207
208
208
## Resolve errors and article
209
209
210
-
To resolve our fields similar to before we go to our schema implementation again and add the resolvers for the
210
+
To resolve our fields similar to before we go to our schema implementation again and add the resolvers for the
211
211
`ArticleResponse` we created (what the mutation now returns back):
212
212
213
213
```php
@@ -232,7 +232,7 @@ public function registerResolvers(ResolverRegistryInterface $registry) {
232
232
}
233
233
```
234
234
235
-
And that's it if we now call this mutation for example as an anonymous user (if we set aribtrary queries enabled in the permissions for the module) we should get an error :
235
+
And that's it if we now call this mutation for example as an anonymous user (if we set arbitrary queries enabled in the permissions for the module) we should get an error :
Copy file name to clipboardexpand all lines: doc/producers/README.md
+7-7
Original file line number
Diff line number
Diff line change
@@ -4,11 +4,11 @@ The 4.x version of the Drupal GraphQL module is built on top of a concept called
4
4
5
5
A data producer is more or less a function that takes arguments (either from an end user query or static) and resolves these into some other data, for example taking an entity (such as a node) and giving back a particular field.
6
6
7
-
Lets imagine we want to make a custom field available for a schema, in this case we have an `author` field in the "Article" content type. For this field we can have a producer that takes an entity and returns or resolves the creator field. Let's apply this to our custom schema which alreay defines an "Article" type.
7
+
Lets imagine we want to make a custom field available for a schema, in this case we have an `author` field in the "Article" content type. For this field we can have a producer that takes an entity and returns or resolves the creator field. Let's apply this to our custom schema which already defines an "Article" type.
8
8
9
9
## Add the field to the schema
10
10
11
-
In your `.graphqls` file add the schema defintion
11
+
In your `.graphqls` file add the schema definition
Now you can make a sample article (as a user) and if you now go over to your graphql explorer and run the following query :
47
+
Now you can make a sample article (as a user) and if you now go over to your graphql explorer and run the following query :
48
48
49
49
```
50
50
{
@@ -54,9 +54,9 @@ Now you can make a sample article (as a user) and if you now go over to your gra
54
54
author
55
55
}
56
56
}
57
-
```
57
+
```
58
58
59
-
You should get a response in the same format e.g. :
59
+
You should get a response in the same format e.g. :
60
60
61
61
```json
62
62
{
@@ -68,11 +68,11 @@ You should get a response in the same format e.g. :
68
68
}
69
69
}
70
70
}
71
-
```
71
+
```
72
72
73
73
### Resolver builder
74
74
75
-
You need to initalize the `ResolverBuilder` once inside the `registerResolvers` method (or `getResolverRegistry` if you do not want to use schema extensions) in order to start registering resolvers. This is what will give you access to all the data producers by calling the `produce` method which takes as a parameter the data producer id.
75
+
You need to initialize the `ResolverBuilder` once inside the `registerResolvers` method (or `getResolverRegistry` if you do not want to use schema extensions) in order to start registering resolvers. This is what will give you access to all the data producers by calling the `produce` method which takes as a parameter the data producer id.
76
76
77
77
Essentially calling the `produce` method with the data producer id is what you need to do every time you want to make a field available in the schema. We tell Drupal where and how to get the data and specify where this maps to.
Copy file name to clipboardexpand all lines: doc/starting/custom-schema.md
+3-3
Original file line number
Diff line number
Diff line change
@@ -20,14 +20,14 @@ This is the main entry point for your schema. You can insert new types, inputs a
20
20
21
21
For now all you need to know about this file is that it extends the base file. What this will allow is to better organize resolvers into different modules where each module might expose different things to the schema. The only existing type by default is `Query` and so to define new queries you have to add them here in the extension.graphqls file.
22
22
23
-
For more information about composable schemas go to [Advanced section](./../advanced/composable-schemas.md) when talking about spliting schemas so that you can make certain modules enable new functionalities as they are enabled.
23
+
For more information about composable schemas go to [Advanced section](./../advanced/composable-schemas.md) when talking about splitting schemas so that you can make certain modules enable new functionalities as they are enabled.
24
24
25
25
### Plugins
26
26
27
27
The module also includes some Plugins which are required inside the folder `src/Plugin/GraphQL/Schema` and optionally `src/Plugin/GraphQL/SchemaExtension`:
28
28
29
-
- ComposableSchemaExample.php : This file will define the schema itself. You can register default resolvers and also regular resolvers here. If you don't have a particular need you don't really need anything more than the anotation for your schema at first. Later with more complex examples we will show how it can be useful to add some base functionality (automatic resolvers or default resolvers).
30
-
- ComposableGraphQLSchemaExtension.php : This file will be used to implement resolvers in a way that is composeable (recommended). We recommend having at least one of these, but you can also implement resolvers across multiple modules by including several schema extensions in each module that exposes certain functionality to the schema when enabled. See the [Advanced section](./../advanced/composable-schemas.md) when talking about spliting schemas.
29
+
- ComposableSchemaExample.php : This file will define the schema itself. You can register default resolvers and also regular resolvers here. If you don't have a particular need you don't really need anything more than the annotation for your schema at first. Later with more complex examples we will show how it can be useful to add some base functionality (automatic resolvers or default resolvers).
30
+
- ComposableGraphQLSchemaExtension.php : This file will be used to implement resolvers in a way that is composable (recommended). We recommend having at least one of these, but you can also implement resolvers across multiple modules by including several schema extensions in each module that exposes certain functionality to the schema when enabled. See the [Advanced section](./../advanced/composable-schemas.md) when talking about splitting schemas.
0 commit comments