-
-
Notifications
You must be signed in to change notification settings - Fork 3
Description
Task: Make authFetch Generic for Type Safety
Objective: Refactor the authFetch utility function to be generic, allowing for compile-time type checking of API responses and improving overall type safety in the frontend.
Problem Description:
The authFetch function (located in frontend/src/lib/authFetch.ts) currently returns data of type any. This leads to a lack of type safety when consuming API responses, requiring manual type assertions or leading to runtime errors if the data structure is not as expected. This was specifically identified in src/components/profile/UserInfoCard.tsx when attempting to use authFetch<ApiUsageStats>.
Proposed Solution:
-
Modify
authFetchsignature: Update the function signature infrontend/src/lib/authFetch.tsto accept a generic type parameterTand return aPromisethat resolves to an object withdata: T | nullanderror: { message: string; status?: number } | null.Example Change:
export async function authFetch<T = any>( endpoint: string, options: FetchWithAuthOptions ): Promise<{ data: T | null; error: { message: string; status?: number } | null }> { // ... existing implementation }
-
Propagate
TtoapiFetchSafe(if applicable): Ensure thatapiFetchSafe(located infrontend/src/lib/api.ts), whichauthFetchinternally uses, also supports generics or is updated to correctly handle the typeT. -
Update Call Sites: Review and update all existing call sites of
authFetchthroughout the frontend to explicitly provide the expected type argument (e.g.,authFetch<MyDataType>('/my-endpoint')). This will immediately highlight any discrepancies between expected and actual API response types.
Acceptance Criteria:
authFetchfunction is generic and correctly infers/validates the type ofresponse.dataat compile time.- All existing usages of
authFetchare updated to use the generic type parameter where appropriate. - No new type errors are introduced by this change.
- The application continues to function correctly at runtime.