Skip to content

Commit 87dbcaf

Browse files
committed
docs(dataproducer): Fix whitespace
1 parent 81bcdad commit 87dbcaf

1 file changed

Lines changed: 15 additions & 15 deletions

File tree

doc/producers/custom.md

Lines changed: 15 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -6,9 +6,9 @@ Custom data producers allow you essentially hook into any data of Drupal, becaus
66

77
Lets look at a custom Data producer that loads the current user (similar to the 3.x version of currentUser query).
88

9-
The first step as seen before is to add our query to the schema :
9+
The first step as seen before is to add our query to the schema :
1010

11-
```
11+
```
1212
type Query {
1313
...
1414
currentUser: User
@@ -21,7 +21,7 @@ type User {
2121
}
2222
```
2323

24-
Now that we have this we need to make a resolver that actually loads this user, but for that first we need our own custom data producer "CurrentUser" :
24+
Now that we have this we need to make a resolver that actually loads this user, but for that first we need our own custom data producer "CurrentUser" :
2525

2626
```php
2727
<?php
@@ -99,7 +99,7 @@ class CurrentUser extends DataProducerPluginBase implements ContainerFactoryPlug
9999

100100
We are defining a custom data producer `current_user` that we can now use to resolve our query that we previously added to the schema. Notice that our data producer returns only the user id and not the actual user object. However we can combine it with an entity_load which is already made very efficient with in the module (taking advantage of caching strategies using buffering) so we don't have to actually load the user here.
101101

102-
Lets see how we can consume our newly created data producer :
102+
Lets see how we can consume our newly created data producer :
103103

104104
```php
105105
$registry->addFieldResolver('Query', 'currentUser', $builder->compose(
@@ -112,7 +112,7 @@ $registry->addFieldResolver('Query', 'currentUser', $builder->compose(
112112

113113
Notice how we combine our custom data producer with a built-in `entity_load` to make querying more performance and standardized across. We will look at `compose` in more detail in the next section.
114114

115-
In the end when we do a query like this :
115+
In the end when we do a query like this :
116116

117117
```graphql
118118
{
@@ -123,7 +123,7 @@ In the end when we do a query like this :
123123
}
124124
```
125125

126-
we get a result like this :
126+
we get a result like this :
127127

128128
```json
129129
{
@@ -138,13 +138,13 @@ we get a result like this :
138138

139139
For this to actually work we would need to add resolvers to the User object to resolve the `id` and `name` properties like so:
140140
```php
141-
$registry->addFieldResolver('User', 'id', $builder->callback(function ($account) {
142-
/** @var \Drupal\Core\Session\AccountProxyInterface $account */
143-
return $account->id();
144-
}));
145-
146-
$registry->addFieldResolver('User', 'name', $builder->callback(function ($account) {
147-
/** @var \Drupal\Core\Session\AccountProxyInterface $account */
148-
return $account->getAccountName();
149-
}));
141+
$registry->addFieldResolver('User', 'id', $builder->callback(function ($account) {
142+
/** @var \Drupal\Core\Session\AccountProxyInterface $account */
143+
return $account->id();
144+
}));
145+
146+
$registry->addFieldResolver('User', 'name', $builder->callback(function ($account) {
147+
/** @var \Drupal\Core\Session\AccountProxyInterface $account */
148+
return $account->getAccountName();
149+
}));
150150
```

0 commit comments

Comments
 (0)