Admin api - #14

src/lib/functions/admin/tag.ts (2)

53-53: Redundant type assertion.

The inputValidator(adminTagsQuerySchema) already provides type inference for data. The as AdminTagsQuery cast is unnecessary and could mask type mismatches if the schema changes.

♻️ Suggested fix

     } = data as AdminTagsQuery;
+    } = data;

---

78-78: Prefer fallback defaults over non-null assertions.

While the schema provides defaults for limit and offset, the non-null assertions (!) obscure this contract. Using inline defaults makes the code more defensive and self-documenting.

♻️ Suggested fix

-        return emptyPaginatedResponse<TagItem>(limit!, offset!);
+        return emptyPaginatedResponse<TagItem>(limit ?? 10, offset ?? 0);

src/lib/functions/admin/product.ts (1)

172-177: Consider using .returning() to avoid a separate re-fetch query.

The update followed by a separate select can be consolidated using Drizzle's .returning() clause for better efficiency.

♻️ Proposed refactor

-    await db.update(products).set({ status }).where(eq(products.id, id));
-
-    const [updatedProduct] = await db
-      .select()
-      .from(products)
-      .where(eq(products.id, id));
+    const [updatedProduct] = await db
+      .update(products)
+      .set({ status })
+      .where(eq(products.id, id))
+      .returning();

src/lib/constants/index.ts (1)

1-4: Optional: narrow the option types with a const assertion.
Helps keep value types literal across the app.

♻️ Suggested tweak

 export const VENDOR_STATUS_OPTIONS = [
   { label: "Active", value: "true" },
   { label: "Inactive", value: "false" },
-];
+] as const;

src/components/containers/shared/coupons/coupon-table.tsx (1)

34-43: Consider type constraints to enforce at least one data source.

Both coupons and fetcher are optional, which means neither could be provided. While the fallback to an empty array is safe, a discriminated union or runtime check could make the API clearer.

♻️ Optional: Use a discriminated union for clearer API

// Option 1: Type-level enforcement
type AdminCouponTableProps = CouponTableActions & {
  className?: string;
  mutationState?: CouponMutationState;
  isCouponMutating?: (id: string) => boolean;
  permissions?: CouponPermissions;
} & (
  | { coupons: CouponItem[]; fetcher?: never }
  | { fetcher: (params: DataTableFetchParams) => Promise<DataTableFetchResult<CouponItem>>; coupons?: never }
);

src/lib/utils/dashboard.ts (1)

83-90: Potential edge case: getStartOfWeek may shift months unexpectedly.

When the current date is early in the month (e.g., March 2nd, which is a Monday), subtracting days to reach Sunday may produce a date in the previous month. The function works correctly, but consumers should be aware this can cross month boundaries.

Additionally, the week start is Sunday (US convention). If the codebase needs Monday-start weeks (ISO 8601), this would need adjustment.

src/components/containers/admin/dashboard/top-shops-list.tsx (1)

21-28: Consider reusing formatCurrency from dashboard utilities.

This helper duplicates formatCurrency from src/lib/utils/dashboard.ts. Importing the shared utility would reduce duplication.

♻️ Import from shared utilities

 import { Link } from "@tanstack/react-router";
 import { ExternalLink, Store } from "lucide-react";
 import { Avatar, AvatarFallback, AvatarImage } from "@/components/ui/avatar";
+import { formatCurrency } from "@/lib/utils/dashboard";
 // ... other imports

 export function TopShopsList({ shops, isLoading = false }: TopShopsListProps) {
-  const formatCurrency = (value: number) => {
-    return new Intl.NumberFormat("en-US", {
-      style: "currency",
-      currency: "USD",
-      minimumFractionDigits: 0,
-      maximumFractionDigits: 0,
-    }).format(value);
-  };
-
   const maxRevenue = Math.max(...shops.map((s) => s.revenue), 1);

src/components/containers/admin/dashboard/revenue-chart.tsx (2)

48-55: Consider reusing formatCurrency from dashboard utilities.

This helper is duplicated in multiple dashboard components. Import from src/lib/utils/dashboard.ts for consistency.

♻️ Import shared utility

+import { formatCurrency } from "@/lib/utils/dashboard";
 // ... other imports

 export function RevenueChart({ data, isLoading = false }: RevenueChartProps) {
   // ... loading state ...

-  const formatCurrency = (value: number) => {
-    return new Intl.NumberFormat("en-US", {
-      style: "currency",
-      currency: "USD",
-      minimumFractionDigits: 0,
-      maximumFractionDigits: 0,
-    }).format(value);
-  };
-
   const formatDate = (dateStr: string) => {

---

83-96: Gradient ID may conflict with multiple chart instances.

The hardcoded id="colorRevenue" could cause issues if multiple RevenueChart components are rendered on the same page. Consider using a unique ID (e.g., via useId hook).

♻️ Use React's useId for unique gradient ID

+import { useId } from "react";

 export function RevenueChart({ data, isLoading = false }: RevenueChartProps) {
+  const gradientId = useId();
   // ...
   
   <defs>
-    <linearGradient id="colorRevenue" x1="0" y1="0" x2="0" y2="1">
+    <linearGradient id={gradientId} x1="0" y1="0" x2="0" y2="1">
       // ...
     </linearGradient>
   </defs>
   // ...
   <Area
     // ...
-    fill="url(`#colorRevenue`)"
+    fill={`url(#${gradientId})`}
   />

src/components/containers/admin/dashboard/top-products-list.tsx (1)

23-30: Use shared currency formatter to avoid duplication.

There’s already a dashboard formatCurrency helper; reusing it keeps formatting consistent and avoids recreating Intl.NumberFormat each render.

♻️ Proposed refactor

-import type { TopProduct } from "@/types/admin-dashboard";
+import type { TopProduct } from "@/types/admin-dashboard";
+import { formatCurrency } from "@/lib/utils/dashboard";
...
-  const formatCurrency = (value: number) => {
-    return new Intl.NumberFormat("en-US", {
-      style: "currency",
-      currency: "USD",
-      minimumFractionDigits: 0,
-      maximumFractionDigits: 0,
-    }).format(value);
-  };

src/components/containers/shared/orders/order-table-columns.tsx (1)

310-523: Consider extracting shared column builders to avoid drift.

createAdminOrderColumns largely mirrors createOrderColumns (status, payment, date, actions). Extracting shared column builders or badge configs would reduce duplication and keep admin/vendor columns in sync.

src/routes/(admin)/admin/products/index.tsx (1)

18-20: Avoid recreating the fetcher on every render.

Creating a new fetcher function each render can cause unnecessary table resets. Consider lifting it to module scope.

♻️ Proposed refactor

+const adminProductsFetcher = createAdminProductsFetcher();
+
 function AdminProductsPage() {
-  const fetcher = createAdminProductsFetcher();
+  const fetcher = adminProductsFetcher;

src/types/taxes.ts (1)

82-90: Consider using PaginatedResponse<NormalizedTaxRate> directly.

TaxRateQueryResult duplicates the exact structure of PaginatedResponse<NormalizedTaxRate>. Since you already import PaginatedResponse and define TaxRateListResponse as an alias, consider making TaxRateQueryResult an alias as well to reduce duplication.

♻️ Suggested simplification

-/**
- * Tax Rate Query Result
- */
-export interface TaxRateQueryResult {
-  data: NormalizedTaxRate[];
-  total: number;
-  limit: number;
-  offset: number;
-}
+/**
+ * Tax Rate Query Result
+ */
+export type TaxRateQueryResult = PaginatedResponse<NormalizedTaxRate>;

src/lib/functions/users.ts (1)

22-32: Avoid any type for better type safety.

The transformUser helper uses any for the input parameter, which bypasses TypeScript's type checking. Consider defining a proper interface for the raw user data from Better Auth.

♻️ Suggested improvement

+interface RawBetterAuthUser {
+  id: string;
+  name?: string | null;
+  email: string;
+  image?: string | null;
+  role?: string | null;
+  banned?: boolean;
+  createdAt: Date | string;
+  updatedAt: Date | string;
+}
+
-const transformUser = (u: any): AdminUser => ({
+const transformUser = (u: RawBetterAuthUser): AdminUser => ({
   id: u.id,
   name: u.name ?? u.email,
   email: u.email,
   image: u.image ?? undefined,
   role: (u.role ?? "customer") as UserRole,
   banned: u.banned ?? false,
   status: u.banned ? "banned" : "active",
   createdAt: u.createdAt,
   updatedAt: u.updatedAt,
 });

src/hooks/admin/use-admin-products.tsx (1)

150-164: Type assertions on mutation variables could be safer.

The type assertions like (deleteProductMutation.variables as string) and (updateStatusMutation.variables?.id as string) could be undefined if the mutation hasn't been called yet. Consider using optional chaining with nullish coalescing to ensure type safety.

♻️ Safer type handling

   const mutationState: AdminProductMutationState = {
     deletingId: deleteProductMutation.isPending
-      ? (deleteProductMutation.variables as string)
+      ? deleteProductMutation.variables ?? null
       : null,
     updatingId: updateStatusMutation.isPending
-      ? (updateStatusMutation.variables?.id as string)
+      ? updateStatusMutation.variables?.id ?? null
       : null,
     togglingId: toggleFeaturedMutation.isPending
-      ? (toggleFeaturedMutation.variables?.id as string)
+      ? toggleFeaturedMutation.variables?.id ?? null
       : null,
     isAnyMutating:
       deleteProductMutation.isPending ||
       updateStatusMutation.isPending ||
       toggleFeaturedMutation.isPending,
   };

src/components/containers/shared/users/add-user-dialog.tsx (1)

45-51: Consider adding password validation.

The password field has no validation rules. Consider adding minimum length and complexity requirements for security.

🛡️ Example with TanStack Form validation

   const form = useForm({
     defaultValues: {
       name: "",
       email: "",
       password: "",
       role: "customer" as UserRole,
     },
+    validators: {
+      onChange: ({ value }) => {
+        const errors: Record<string, string> = {};
+        if (value.password && value.password.length < 8) {
+          errors.password = "Password must be at least 8 characters";
+        }
+        return Object.keys(errors).length > 0 ? errors : undefined;
+      },
+    },
     onSubmit: async ({ value }) => {

src/lib/functions/admin/coupon.ts (1)

179-183: Empty conditional block is a code smell.

The if (existingCoupon.usageCount > 0) block is empty with only a comment. Either implement the soft delete logic, add a warning response, or remove the check entirely to avoid dead code.

♻️ Option 1: Add warning in response

     // Check usage count
     if (existingCoupon.usageCount > 0) {
-      // Soft delete might be preferred, but for now we'll allow deletion
-      // You could add a warning here if needed
+      // Warn that this coupon has been used
+      await db.delete(coupons).where(eq(coupons.id, id));
+      return createSuccessResponse(
+        `Coupon deleted successfully. Note: This coupon had ${existingCoupon.usageCount} uses.`
+      );
     }

     await db.delete(coupons).where(eq(coupons.id, id));

♻️ Option 2: Remove the empty check

-    // Check usage count
-    if (existingCoupon.usageCount > 0) {
-      // Soft delete might be preferred, but for now we'll allow deletion
-      // You could add a warning here if needed
-    }
-
     await db.delete(coupons).where(eq(coupons.id, id));

src/hooks/admin/use-admin-orders.tsx (2)

21-32: Minor: Query key structure differs from other admin hooks.

This file uses a flat ["admin-orders"] base key while use-admin-tags.tsx uses a nested ["admin", "tags"] structure. Consider aligning the pattern for consistency across admin hooks.

 export const adminOrderKeys = {
-  all: ["admin-orders"] as const,
+  all: ["admin", "orders"] as const,
   list: (params?: {

---

78-131: Missing error handlers in mutations.

Unlike useAdminTagMutations which provides toast notifications on errors, these mutation hooks lack onError callbacks. Consider adding error handling for consistent user feedback.

Proposed fix for useUpdateAdminOrderStatus

     onSuccess: (_, variables) => {
       queryClient.invalidateQueries({ queryKey: adminOrderKeys.all });
       queryClient.invalidateQueries({
         queryKey: adminOrderKeys.detail(variables.orderId),
       });
     },
+    onError: (error: Error) => {
+      toast.error(error.message || "Failed to update order status");
+    },
   });

src/components/containers/admin/dashboard/recent-orders-table.tsx (1)

54-59: Consider reusing existing formatCurrency utility.

A formatCurrency function already exists in src/lib/utils/dashboard.ts. The implementations differ slightly (this one includes decimal places, the utility doesn't), but consider consolidating to avoid duplication. If decimal precision is needed here, the shared utility could be parameterized.

+import { formatCurrency } from "@/lib/utils/dashboard";
+
+// If decimals needed, create a variant or add a parameter to the shared utility

src/components/containers/shared/reviews/review-table-columns.tsx (1)

170-172: "View Details" action has no handler.

The "View Details" menu item is rendered when permissions?.canView is true, but it lacks an onClick handler. Consider either implementing the action or adding a TODO comment.

src/types/transaction.ts (1)

44-54: Consider using a stricter type for status.

TransactionBaseResponse.status is typed as string, but based on the validator in transaction.ts server file (line 29), it should be one of "pending" | "processing" | "succeeded" | "failed" | "refunded". Using a union type would provide better type safety.

♻️ Proposed type refinement

+export type TransactionStatus = "pending" | "processing" | "succeeded" | "failed" | "refunded";
+
 export interface TransactionBaseResponse {
   id: string;
   paymentIntentId: string | null;
   orderId: string;
   orderNumber: string;
   currency: string;
-  status: string;
+  status: TransactionStatus;
   paymentMethod: string;
   provider: string;
   createdAt: string;
 }

src/components/containers/admin/transactions/admin-transactions-table.tsx (1)

136-141: "View Details" action is a placeholder.

Similar to the review table, the "View Details" menu item lacks an onClick handler. Consider implementing navigation to a transaction detail view or adding a TODO.

src/hooks/admin/use-admin-entity-fetchers.ts (1)

36-46: Consider avoiding any for the query type parameter.

Using any for the second generic parameter in createServerFetcher<NormalizedCategory, any> loses type safety. If the query shape is consistent across fetchers, consider defining a shared query type.

src/routes/(admin)/admin/brands/index.tsx (1)

16-16: Consider memoizing the fetcher to prevent unnecessary re-fetches.

createAdminBrandsFetcher() is called on every render, creating a new function reference each time. This may cause the DataTable to re-fetch data on every parent re-render since the fetcher reference changes.

♻️ Proposed fix using useMemo

+import { useMemo } from "react";
...
 function AdminBrandsPage() {
-  const fetcher = createAdminBrandsFetcher();
+  const fetcher = useMemo(() => createAdminBrandsFetcher(), []);

src/routes/(admin)/admin/users/index.tsx (1)

10-13: Missing pendingComponent for route loading state.

Other admin routes (brands, taxes, attributes) include pendingComponent: PageSkeleton in their route configuration for consistent loading UX during route transitions. This route handles loading manually via isLoading check, but the route-level pending state is not covered.

♻️ Proposed fix to add pendingComponent

 export const Route = createFileRoute("/(admin)/admin/users/")({
   component: AdminUsersPage,
+  pendingComponent: PageSkeleton,
 });

src/components/templates/admin/admin-dashboard-template.tsx (2)

33-48: Consider handling error states for dashboard queries.

The dashboard fetches data from 9 different hooks, but none handle error states. If a query fails, the corresponding section will remain in a loading state indefinitely. Consider either:

1. Adding error boundaries around sections
2. Passing isError to child components for graceful degradation
3. Using a consolidated error indicator

---

85-91: Minor: changeLabel displays "+0 today" when no new users.

When stats?.newUsersToday is 0 or undefined, the label will show "+0 today" which may look odd. Consider conditionally displaying this only when there are new users.

♻️ Optional fix for cleaner display

         <StatsCard
           title="Total Users"
           value={stats?.totalUsers || 0}
-          changeLabel={`+${stats?.newUsersToday || 0} today`}
+          changeLabel={stats?.newUsersToday ? `+${stats.newUsersToday} today` : undefined}
           icon={Users}
           isLoading={statsLoading}
         />

src/routes/(admin)/admin/taxes/index.tsx (1)

16-16: Consider memoizing the fetcher to prevent unnecessary re-fetches.

Same as the brands route, createAdminTaxRatesFetcher() is called on every render. Consider memoizing for consistency and to prevent potential re-fetch issues.

♻️ Proposed fix using useMemo

+import { useMemo } from "react";
...
 function AdminTaxesPage() {
-  const fetcher = createAdminTaxRatesFetcher();
+  const fetcher = useMemo(() => createAdminTaxRatesFetcher(), []);

src/routes/(admin)/admin/attributes/index.tsx (2)

17-17: Consider memoizing the fetcher to prevent unnecessary re-fetches.

Consistent with other admin routes, the fetcher should be memoized to maintain stable reference across renders.

♻️ Proposed fix using useMemo

+import { useMemo } from "react";
...
 function AdminAttributesPage() {
-  const fetcher = createAdminAttributesFetcher();
+  const fetcher = useMemo(() => createAdminAttributesFetcher(), []);

---

75-99: Redundant handleDialogClose call in onOpenChange.

When the dialog closes (open becomes false), both setIsDialogOpen(open) and handleDialogClose() are called. Looking at useEntityCRUD, handleDialogClose likely already calls setIsDialogOpen(false), resulting in redundant state updates. Additionally, handleDialogClose is called in handleAttributeSubmit on success, which may cause the cleanup to run twice.

♻️ Proposed simplification

       <AddAttributeDialog
         open={isDialogOpen}
-        onOpenChange={(open) => {
-          setIsDialogOpen(open);
-          if (!open) handleDialogClose();
-        }}
+        onOpenChange={setIsDialogOpen}
         onSubmit={handleAttributeSubmit}

If handleDialogClose needs to clear editingAttribute, ensure that's handled appropriately when the dialog closes without submitting.

src/routes/(admin)/admin/categories/index.tsx (1)

16-16: Fetcher recreated on every render — memoize or hoist outside component.

createAdminCategoriesFetcher() is called directly in the component body, creating a new fetcher function instance on each render. This can cause the underlying DataTable to treat it as a new fetcher, potentially triggering unnecessary re-fetches or disrupting caching behavior.

♻️ Proposed fix: memoize the fetcher

+import { useMemo } from "react";
...

 function AdminCategoriesPage() {
-  const fetcher = createAdminCategoriesFetcher();
+  const fetcher = useMemo(() => createAdminCategoriesFetcher(), []);

Alternatively, if the fetcher doesn't depend on component state, hoist it outside the component entirely.

src/hooks/admin/use-admin-attributes.tsx (1)

134-156: Comment claims optimistic updates, but none are implemented.

The comment on line 134 mentions "optimistic updates," but the onMutate handler only cancels queries and returns context for potential rollback — no cache modification occurs. This is technically a "cancel + refetch" pattern rather than true optimistic updates. Consider either implementing actual optimistic cache updates or updating the comment to reflect the current behavior.

src/hooks/admin/use-admin-taxes.tsx (1)

53-61: Consider adding staleTime for consistency with other admin hooks.

Other admin hooks (e.g., use-admin-attributes.tsx) specify a staleTime (30s for lists, 60s for details). This hook omits it, defaulting to 0, which may cause more frequent refetches.

♻️ Proposed fix: add staleTime

   return queryOptions({
     queryKey: adminTaxRatesKeys.list(mergedParams),
     queryFn: () => getAdminTaxRates({ data: mergedParams }),
+    staleTime: 30 * 1000, // 30 seconds
   });

src/hooks/admin/use-admin-categories.tsx (2)

138-151: togglingId conflates two different mutations — may cause incorrect loading indicators.

The togglingId field combines toggleActiveMutation.variables?.id and toggleFeaturedMutation.variables?.id using ||. If both mutations were somehow pending simultaneously (edge case), only one ID would be tracked. More critically, UI consumers cannot distinguish whether the toggle is for isActive or featured status.

Consider splitting into separate tracking fields if the UI needs to differentiate these states.

♻️ Proposed fix: separate tracking for each toggle type

 const mutationState: AdminCategoryMutationState = {
   deletingId: deleteCategoryMutation.isPending
     ? (deleteCategoryMutation.variables as string)
     : null,
-  togglingId:
-    toggleActiveMutation.isPending || toggleFeaturedMutation.isPending
-      ? ((toggleActiveMutation.variables?.id ||
-          toggleFeaturedMutation.variables?.id) as string)
-      : null,
+  togglingActiveId: toggleActiveMutation.isPending
+    ? (toggleActiveMutation.variables?.id ?? null)
+    : null,
+  togglingFeaturedId: toggleFeaturedMutation.isPending
+    ? (toggleFeaturedMutation.variables?.id ?? null)
+    : null,
   isAnyMutating:
     deleteCategoryMutation.isPending ||
     toggleActiveMutation.isPending ||
     toggleFeaturedMutation.isPending,
 };

This would require updating AdminCategoryMutationState and consumers accordingly.

---

54-72: Consider adding staleTime for consistency.

Similar to the tax rates hook, this lacks explicit staleTime configuration while other admin hooks specify it.

src/components/templates/admin/admin-transactions-template.tsx (1)

85-86: Consider formatting large transaction counts.

stats.totalTransactions is rendered directly without number formatting. For large values (e.g., 1,000,000+), this could be harder to read. Consider using Intl.NumberFormat or a formatting utility for consistency with the currency values.

♻️ Proposed fix

 <div className="font-bold text-2xl">
-  {stats.totalTransactions}
+  {stats.totalTransactions.toLocaleString()}
 </div>

src/hooks/admin/use-admin-reviews.tsx (1)

140-143: Inconsistent mutation return pattern compared to other admin hooks.

Other admin hooks (e.g., useAdminAttributeMutations, useAdminCategoryMutations, useAdminTaxRateMutations) return mutateAsync functions directly along with mutationState and is*Mutating helpers:

return {
  toggleActive: toggleActiveMutation.mutateAsync,
  mutationState,
  isAttributeMutating: (id) => ...
};

This hook returns the full mutation objects instead:

return {
  updateStatus: updateStatusMutation,
  deleteReview: deleteReviewMutation,
};

Consider aligning with the established pattern for consistency across admin hooks.

♻️ Proposed fix: align with other admin hooks

+interface AdminReviewMutationState {
+  updatingStatusId: string | null;
+  deletingId: string | null;
+  isAnyMutating: boolean;
+}

 export function useAdminReviewMutations() {
   const queryClient = useQueryClient();
   // ... existing mutation definitions ...

+  const mutationState: AdminReviewMutationState = {
+    updatingStatusId: updateStatusMutation.isPending
+      ? (updateStatusMutation.variables?.reviewId ?? null)
+      : null,
+    deletingId: deleteReviewMutation.isPending
+      ? (deleteReviewMutation.variables?.reviewId ?? null)
+      : null,
+    isAnyMutating:
+      updateStatusMutation.isPending || deleteReviewMutation.isPending,
+  };

   return {
-    updateStatus: updateStatusMutation,
-    deleteReview: deleteReviewMutation,
+    updateStatus: updateStatusMutation.mutateAsync,
+    deleteReview: deleteReviewMutation.mutateAsync,
+    isUpdatingStatus: updateStatusMutation.isPending,
+    isDeleting: deleteReviewMutation.isPending,
+    mutationState,
+    isReviewMutating: (reviewId: string) =>
+      mutationState.updatingStatusId === reviewId ||
+      mutationState.deletingId === reviewId,
   };
 }

src/components/containers/shared/users/user-table.tsx (2)

157-165: Hardcoded role values could drift from the UserRole type.

The role options are hardcoded as string literals. If UserRole is updated, this menu won't reflect the changes and may cause runtime issues.

♻️ Consider deriving options from UserRole type

If UserRole is a union type or enum, consider deriving the options programmatically:

// If UserRole is defined as: type UserRole = "customer" | "vendor" | "admin"
const ROLE_OPTIONS: { value: UserRole; label: string }[] = [
  { value: "customer", label: "Customer" },
  { value: "vendor", label: "Vendor" },
  { value: "admin", label: "Admin" },
];

Then map over ROLE_OPTIONS in the JSX. This keeps the source of truth in one place.

---

100-113: Status badge handles only "banned" and "active" states.

The badge logic applies destructive styling for "banned" and green for "active", but any other status value would fall through to the default variant without specific styling. If additional statuses exist (e.g., "suspended", "pending"), they may need handling.

src/routes/(admin)/admin/reviews/index.tsx (1)

52-54: Consider replacing window.prompt() with a proper dialog input.

window.prompt() provides a poor user experience—it's blocking, cannot be styled, and looks inconsistent across browsers. A custom dialog component with an input field would provide better UX and allow proper validation feedback.

src/lib/functions/admin/review.ts (1)

212-213: Replace console.log with proper audit logging.

The comment acknowledges this should be stored in production. Using console.log for admin deletion audit trails has several issues:

• Logs are ephemeral and may be lost
• No structured format for querying/analysis
• PII (deletion reason) in logs without proper handling

Consider storing to an audit table or using a structured logging service.

♻️ Suggested approach

-    // Log deletion reason (in production, you might want to store this)
-    console.log(`Admin deleted review ${reviewId}. Reason: ${reason}`);
+    // TODO: Store deletion audit to database or structured logging service
+    // Example: await db.insert(auditLogs).values({
+    //   action: 'REVIEW_DELETED',
+    //   entityId: reviewId,
+    //   reason,
+    //   adminId: ctx.user.id, // if available from middleware context
+    //   timestamp: new Date(),
+    // });

src/hooks/admin/use-users.tsx (1)

56-61: Remove as any type cast and align role types properly.

The role parameter on lines 60 and 117 is cast to any, which bypasses type safety. Since UserRole is already properly typed as "admin" | "vendor" | "customer", consider:

1. Checking if better-auth's admin client supports the UserRole type directly without casting
2. If not, create a type-safe mapping function instead of using as any
3. Verify the admin client's role parameter type in better-auth's type definitions and update accordingly