Skip to content

Task: Make Generic for Type Safety #217

@rogasp

Description

@rogasp

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:

  1. Modify authFetch signature: Update the function signature in frontend/src/lib/authFetch.ts to accept a generic type parameter T and return a Promise that resolves to an object with data: T | null and error: { 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
    }
  2. Propagate T to apiFetchSafe (if applicable): Ensure that apiFetchSafe (located in frontend/src/lib/api.ts), which authFetch internally uses, also supports generics or is updated to correctly handle the type T.

  3. Update Call Sites: Review and update all existing call sites of authFetch throughout 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:

  • authFetch function is generic and correctly infers/validates the type of response.data at compile time.
  • All existing usages of authFetch are 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions