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
Enhance the types for API Routes and Edge Functions
Non-Goals
Replace libraries like tRPC, react-query and graphql
Background
The current rise of awesome libraries like tRPC shows that having type safety across your stack is a thing that many developers like. It just makes it so much easier to ship changes with confidence.
I also think that existing solutions that are unable to migrate to a library like tRPC and / or just want a leaner solution by just using the api routes (with or without the edge runtime).
It is currently possible to type the NextApiResponse and use the type which is used there to type the fetch call in the frontend. I do also think that inferring the type from the the handler itself is a cleaner and less error-prone way.
Proposal
I think the NextApiResponse and NextResponse functions should be extended to also hold the type of the returned value. (e.g. calling res.json({ name: "John Doe" }) should result in a NextApiResponse<{ name: "John Doe" }> rather than NextApiResponse. The same applies to the NextResponse class used in the edge runtime.
This would enable us to create a type that is able to infer the potential returned values from this API route (called InferVal in the example repo). This type could then be exported from the handler (e.g. /api/test.ts) and be imported using a import type import to prevent importing server code on the client.
The only caveat here would be that the user would actually need to return res.json or res.send rather than just calling it in order to get full type-safety. Edge functions need to return a NextResponse either way.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Goals
Non-Goals
Background
The current rise of awesome libraries like tRPC shows that having type safety across your stack is a thing that many developers like. It just makes it so much easier to ship changes with confidence.
I also think that existing solutions that are unable to migrate to a library like tRPC and / or just want a leaner solution by just using the api routes (with or without the edge runtime).
It is currently possible to type the
NextApiResponse
and use the type which is used there to type thefetch
call in the frontend. I do also think that inferring the type from the the handler itself is a cleaner and less error-prone way.Proposal
I think the
NextApiResponse
andNextResponse
functions should be extended to also hold the type of the returned value. (e.g. callingres.json({ name: "John Doe" })
should result in aNextApiResponse<{ name: "John Doe" }>
rather thanNextApiResponse
. The same applies to theNextResponse
class used in the edge runtime.This would enable us to create a type that is able to infer the potential returned values from this API route (called
InferVal
in the example repo). This type could then be exported from the handler (e.g./api/test.ts
) and be imported using aimport type
import to prevent importing server code on the client.The only caveat here would be that the user would actually need to return
res.json
orres.send
rather than just calling it in order to get full type-safety. Edge functions need to return aNextResponse
either way.Example
https://stackblitz.com/edit/nextjs-ng5stq?file=pages/api/time.ts
I would be willing to work on this as most of the work is already done and I will try to create a PR for this :)
Beta Was this translation helpful? Give feedback.
All reactions