-
-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TypeScript Handler Type Incompatibility with AuthenticatedRequest in Fastify #1058
Comments
I didn't check the code, but something like this should work:
|
It did not worked. There is still type incompatibility error. Error message vscode produce: Type '(request: AuthenticatedRequest<{ Body: z.infer; }>, response: FastifyReply) => Promise' is not assignable to type 'RouteHandlerMethod<RawServerDefault, IncomingMessage, ServerResponse, RouteGenericInterface, unknown, FastifySchema, FastifyTypeProviderDefault, FastifyBaseLogger>'. |
Also didn't find a solution and just use patch-package for |
For more details and context, you can view my codebase here: https://github.com/Prag1974/writings-backend
I am building a web API using Fastify with TypeScript. My project utilizes the following packages:
Problem Description
I have set up route (./src/session/route.ts) that require authentication for all endpoints located in it and have added a preHandler hook for these routes to verify if the user is authenticated. Since the preHandler ensures authentication, request.user should always be defined in the subsequent route handlers.
Here is the mentioned route:
Here is the declaration of checkAuthentication function
So, all endpoints located in the route ensure that request.user is not optional. But declaration made in FastifyRequst still claims that request.user might be nullish (normally). But I did want to prevail that situation by creating a new interface which user property definitely defined and I would be, finally, able to use it by not concerning about it if it is nullish, since I already checked that it is not.
Afterwards, I used that interface in my handler function declarations e.g:
That all works, there was no problem until my endpoint declarations are yelling:
Here is the one of the error messages from my endpoints:
The problem is how can I solve this situation? Because I am ensure that request.user is not null or undefined as I already checked it before, hence, I wanna use it freely. Here is the some AI advices to solve that situation and the reason behind why I didn't want to use them:
What I've Tried
1. Type Assertions Inside Handlers
Using a type assertion within the handler:
Why this doesn't meet my requirements: I want to avoid type assertions inside handlers to keep the code clean and maintain adherence to coding standards. It still violates DRY and damaging the readability as well as memory.
2. Non-Null Assertions
Using the non-null assertion operator:
Why this doesn't meet my requirements: Non-null assertions are discouraged by ESLint rules and general coding practices I follow. Also it is require to use ! operator whenver I am supposed to access user object. It comes an unnecessary usage. I guess there is another solution to meet this problem.
3. Wrapping Handlers with Higher-Order Functions
Creating a higher-order function to wrap the handler:
Why this doesn't meet my requirements: Wrapping each handler function individually violates the DRY principle and reduces code readability.
Constraints and Requirements
I aim to achieve the following:
As I mentioned before, you can check my code: https://github.com/Prag1974/writings-backend
I understand that this is a complex issue involving TypeScript's type system and Fastify's handler expectations. If there are any recommended practices or patterns within Fastify to handle such cases, I'd be grateful to learn about them.
Independently of this goal I envisaged (declaring a new type with property "user" and use it coherently and without any problem.), can you suggest another solution or solution path for this problem? What other solutions can I apply to this problem without violating coding principles, without disrupting readability and overall structure?
I hope I have made my problem clear. If there is anything you don't completely understand, please contact me or provide an answer to this issue. I appreciate any guidance or solutions that can help resolve this issue while adhering to the outlined constraints. Thank you in advance for your assistance! Lastly, please pardon my English.
The text was updated successfully, but these errors were encountered: