Skip to content

Commit 471e34b

Browse files
docs(): document passthrough option
1 parent 5a35fac commit 471e34b

File tree

1 file changed

+22
-4
lines changed

1 file changed

+22
-4
lines changed

content/controllers.md

Lines changed: 22 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -58,12 +58,12 @@ This method will return a 200 status code and the associated response, which in
5858
<tr>
5959
<td>Library-specific</td>
6060
<td>
61-
We can use the library-specific (e.g., Express) <a href="https://expressjs.com/en/api.html#res" rel="nofollow" target="_blank">response object</a>, which can be injected using the <code>@Res()</code> decorator in the method handler signature (e.g., <code>findAll(@Res() response)</code>). With this approach, you have the ability (and the responsibility), to use the native response handling methods exposed by that object. For example, with Express, you can construct responses using code like <code>response.status(200).send()</code>
61+
We can use the library-specific (e.g., Express) <a href="https://expressjs.com/en/api.html#res" rel="nofollow" target="_blank">response object</a>, which can be injected using the <code>@Res()</code> decorator in the method handler signature (e.g., <code>findAll(@Res() response)</code>). With this approach, you have the ability to use the native response handling methods exposed by that object. For example, with Express, you can construct responses using code like <code>response.status(200).send()</code>.
6262
</td>
6363
</tr>
6464
</table>
6565

66-
> warning **Warning** You cannot use both approaches at the same time. Nest detects when the handler is using either `@Res()` or `@Next()`, indicating you have chosen the library-specific option. If both approaches are used at the same time, the Standard approach is **automatically disabled** for this single route and will no longer work as expected.
66+
> warning **Warning** Nest detects when the handler is using either `@Res()` or `@Next()`, indicating you have chosen the library-specific option. If both approaches are used at the same time, the Standard approach is **automatically disabled** for this single route and will no longer work as expected. To use both approaches at the same time (for example, by injecting the response object to only set cookies/headers but still leave the rest to the framework), you must set the `passthrough` option to `true` in the `@Res({{ '{' }} passthrough: true {{ '}' }})` decorator.
6767
6868
<app-banner-enterprise></app-banner-enterprise>
6969

@@ -546,6 +546,24 @@ export class CatsController {
546546
}
547547
```
548548
549-
Though this approach works, and does in fact allow for more flexibility in some ways by providing full control of the response object (headers manipulation, library-specific features, and so on), it should be used with care. In general, the approach is much less clear and does have some disadvantages. The main disadvantages are that you lose compatibility with Nest features that depend on Nest standard response handling, such as Interceptors and the `@HttpCode()` decorator. Also, your code can become platform-dependent (as underlying libraries may have different APIs on the response object), and harder to test (you'll have to mock the response object, etc.).
549+
Though this approach works, and does in fact allow for more flexibility in some ways by providing full control of the response object (headers manipulation, library-specific features, and so on), it should be used with care. In general, the approach is much less clear and does have some disadvantages. The main disadvantage is that your code become platform-dependent (as underlying libraries may have different APIs on the response object), and harder to test (you'll have to mock the response object, etc.).
550550
551-
As a result, the Nest standard approach should always be preferred when possible.
551+
Also, in the example above, you lose compatibility with Nest features that depend on Nest standard response handling, such as Interceptors and `@HttpCode()` / `@Header()` decorators. To fix this, you can set the `passthrough` option to `true`, as follows:
552+
553+
```typescript
554+
@@filename()
555+
@Get()
556+
findAll(@Res({ passthrough: true }) res: Response) {
557+
res.status(HttpStatus.OK);
558+
return [];
559+
}
560+
@@switch
561+
@Get()
562+
@Bind(Res({ passthrough: true }))
563+
findAll(res) {
564+
res.status(HttpStatus.OK);
565+
return [];
566+
}
567+
```
568+
569+
Now you can interact with the native response object (for example, set cookies or headers depending on certain conditions), but leave the rest to the framework.

0 commit comments

Comments
 (0)