Errors and feedback

Toasts, API error shapes, and network handling in ApiTables

Files: ./ApiTables/table-utils/errorHandling.ts, plus sonner toasts from ./ApiTables/table-utils/utils.tsx (clipboard).

Success and validation (handleResponseErrors)

Used after row and bulk POSTs (inside useUtilsProvider) when the response is normal JSON (not blob export).

Response shapeUI
data.success === trueRuns success callback; optional toast.success(message)
data.message without success/errorstoast.error(message)
data.errors as arrayOne toast per item
data.errors as stringSingle error toast
data.errors as objectToasts joined field errors
Failure without errorsError callback only

Backend teams should keep success, errors, and message consistent so the UI behaves predictably.

Network errors (handleNetworkErrors)

Used by useTableFetcher and action POST catch blocks.

CaseBehavior
HTTP 401Calls internalAxios.delete("/api/delete-auth"); redirects to /login on success
Cancelled request (ERR_CANCELED)Silent return (in-flight fetch aborted)
response.data.error string or arrayError toast(s)
Fallbacktoast.error(err.message || "Something went wrong!")

Aborted fetches in useTableFetcher leave loading true when cancelled (by design) so a replacement request can finish.

User-initiated copy

copyToClipboard in utils.tsx shows a success toast (default Arabic message "تم النسخ" unless overridden).

Global loader (not in errorHandling)

Bulk actions dispatch _setMainLoader on the app store during POST — see useUtilsProvider. That is separate from table-local loading flags.

On this page