|
### `getDecorator<T>` API |
|
|
|
Fastify's `getDecorator<T>` API retrieves an existing decorator from the |
|
Fastify instance, `Request`, or `Reply`. If the decorator is not defined, an |
|
`FST_ERR_DEC_UNDECLARED` error is thrown. |
|
|
|
#### Use cases |
|
|
|
**Early Plugin Dependency Validation** |
|
|
|
`getDecorator<T>` on Fastify instance verifies that required decorators are |
|
available at registration time. |
|
|
|
For example: |
|
|
|
```js |
|
fastify.register(async function (fastify) { |
|
const usersRepository = fastify.getDecorator('usersRepository') |
|
|
|
fastify.get('/users', async function (request, reply) { |
|
// We are sure `usersRepository` exists at runtime |
|
return usersRepository.findAll() |
|
}) |
|
}) |
|
``` |
In the middle of the decorators API documentation there is suddenly non-JavaScript syntax that is contrary to the rest of the document. When it was linked in a discussion, I was very confused about what document I was reading. I thought I was reading our TypeScript specific document, but I wasn't. I was particularly confused because the code snippets didn't show what the <T> thing was doing or why it is necessary.
I think this section of the documentation should be updated to match its surroundings. It should simply document the method in the same style as the other decorator access methods:
|
#### `hasDecorator(name)` |
|
<a id="has-decorator"></a> |
|
|
|
Used to check for the existence of a server instance decoration: |
|
|
|
```js |
|
fastify.hasDecorator('utility') |
|
``` |
|
|
|
#### hasRequestDecorator |
|
<a id="has-request-decorator"></a> |
|
|
|
Used to check for the existence of a Request decoration: |
|
|
|
```js |
|
fastify.hasRequestDecorator('utility') |
|
``` |
|
|
|
#### hasReplyDecorator |
|
<a id="has-reply-decorator"></a> |
|
|
|
Used to check for the existence of a Reply decoration: |
|
|
|
```js |
|
fastify.hasReplyDecorator('utility') |
|
``` |