update proxy docs to use NextProxy type#90647
Conversation
|
Allow CI Workflow Run
Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer |
There was a problem hiding this comment.
Thanks for the PR! NextProxy I agree, we need to document this.
However, converting every single example to use NextProxy + arrow functions introduces a lot of stylistic churn without improving clarity. In fact, it makes most examples less clear, users lose sight of what request actually is (NextRequest, which extends Request), and the arrow function conversion in JS examples has zero benefit.
A better approach would be to:
- Keep the existing examples as-is explicit
request: NextRequestis more pedagogical for reference docs, and it also makes it easier to introduceeventargument, I'd argue anyway. - Add a dedicated example snippet (e.g., in the Params section or near the top, or right at the end of the Examples section) that shows the
NextProxytyped pattern, explaining that it infers parameter types (NextRequest,NextFetchEvent) so you don't need to import them individually. This is where showing both styles side-by-side would be valuable, it teaches users the shorthand and what the actual parameter types are.
That way the type gets proper visibility without losing explicitness everywhere else.
|
a bit unrelated but the vercel cron docs can benefit from the same improvement by using the 
|
| export const proxy: NextProxy = (request, event) => { | ||
| event.waitUntil(Promise.resolve()) | ||
| return Response.json({ pathname: request.nextUrl.pathname }) | ||
| } |
There was a problem hiding this comment.
For anyone else arriving here, we did have NextMiddleware too, a bit too late 🥲
|
is there a similar type for next route handlers so we don't have to type the params manually? |
### What? Updated all proxy code examples in the API reference to use the `NextProxy` typed arrow function pattern, consistent with the convention used in `src/proxy.ts`. ### Why? The proxy function is typed as `NextProxy` so parameters are inferred from the type, removing the need for explicit `NextRequest` imports. ### How? Updated all proxy code examples in the API reference to use the `NextProxy` typed arrow function pattern, consistent with the convention used in `src/proxy.ts`. --------- Co-authored-by: Joseph <sephxd1234@gmail.com> Co-authored-by: Joseph <joseph.chamochumbi@vercel.com>
What?
Updated all proxy code examples in the API reference to use the
NextProxytyped arrow function pattern, consistent with the convention used insrc/proxy.ts.Why?
The proxy function is typed as
NextProxyso parameters are inferred from the type, removing the need for explicitNextRequestimports.How?
Updated all proxy code examples in the API reference to use the
NextProxytyped arrow function pattern, consistent with the convention used insrc/proxy.ts.