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: docs/api/schema/resolvers.md
+23-28Lines changed: 23 additions & 28 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,7 @@
1
1
---
2
2
outline: deep
3
3
---
4
+
4
5
# Resolvers
5
6
6
7
Resolvers dynamically resolve individual properties based on a context, in a Feathers application usually the [hook context](../hooks.md#hook-context).
Property resolvers are a map of property names to resolver functions. A resolver function is an `async` function that resolves a property on a data object. If it returns `undefined` the property will not be included. It gets passed the following parameters:
75
+
Property resolvers are a map of property names to resolver functions. A resolver function is an `async`or regular function that resolves a property on a data object. If it returns `undefined` the property will not be included. It gets passed the following parameters:
75
76
76
77
-`value` - The current value which can also be `undefined`
@@ -126,7 +127,7 @@ Virtual resolvers should always be used when combined with a [database adapter](
126
127
127
128
A resolver takes the following options as the second parameter:
128
129
129
-
-`converter` (optional): A `async (data, context) => {}` function that can return a completely new representation of the data. A `converter` runs before `properties` resolvers.
130
+
-`converter` (optional): A `(data, context) => {}` or `async (data, context) => {}` function that can return a completely new representation of the data. A `converter` runs before `properties` resolvers.
130
131
131
132
```ts
132
133
const userResolver =resolve<User, MyContext>(
@@ -185,22 +186,16 @@ type MessageData = Static<typeof messageDataSchema>
185
186
186
187
// Resolver that automatically set `userId` and `createdAt`
// Always hide the password for external responses
304
-
password: async() =>undefined
300
+
password: () =>undefined
305
301
})
306
302
307
303
// Dispatch should be resolved on every method
@@ -324,11 +320,11 @@ In order to get the safe data from resolved associations **all services** involv
324
320
325
321
Query resolvers use the `hooks.resolveQuery(...resolvers)` hook to modify `params.query`. This is often used to set default values or limit the query so a user can only request data they are allowed to see. It is possible to pass multiple resolvers which will run in the order they are passed, using the previous data. `schemaHooks.resolveQuery` can be used as an `around` or `before` hook.
326
322
327
-
In this example for a `User` schema we are first checking if a user is available in our request. In the case a user is available we are returning the user's ID. Otherwise we return whatever value was provided for `id`.
323
+
In this example for a `User` schema we are first checking if a user is available in our request. In the case a user is available we are returning the user's ID. Otherwise we return whatever value was provided for `id`.
328
324
329
325
`context.params.user` would only be set if the request contains a user. This is usually the case when an external request is made. In the case of an internal request we may not have a specific user we are dealing with, and we will just return `value`.
330
326
331
-
If we were to receive an internal request, such as `app.service('users').get(123)`, `context.params.user` would be `undefined` and we would just return the `value` which is `123`.
327
+
If we were to receive an internal request, such as `app.service('users').get(123)`, `context.params.user` would be `undefined` and we would just return the `value` which is `123`.
// If there is an authenticated user, they can only see their own data
356
-
id: async(value, query, context) => {
352
+
id: (value, query, context) => {
357
353
if (context.params.user) {
358
354
returncontext.params.user.id
359
355
}
@@ -372,7 +368,7 @@ app.service('users').hooks({
372
368
373
369
For a more complicated example. We will make a separate `queryResolver`, called `companyFilterQueryResolver`, that will act as a ownership filter. We will have a `Company` service that is owned by a `User`. We will assume our app has two registered users and two companies. Each user owning one company. For simplicity, `User1` owns `Company1`, and `User2` owns `Company2`
374
370
375
-
We want to make sure only the user that owns the company can make any requests related to it. Our schema contains a `ownerUser` field, this is the owner of the company. When a request is made to the company schema, we are effectivly filtering our search for companies to be only those whose `ownerUser` matches the requesting user's id.
371
+
We want to make sure only the user that owns the company can make any requests related to it. Our schema contains a `ownerUser` field, this is the owner of the company. When a request is made to the company schema, we are effectivly filtering our search for companies to be only those whose `ownerUser` matches the requesting user's id.
376
372
377
373
So if a `GET /company` request is made by `User1`, our resolver will convert our query to `GET /company?name=Company1&ownerUser={User1.id}`. The result will only return an array of 1 company to `User1`
0 commit comments