API fails gracefully with partial UI rendering

When an API call fails, applications that render nothing leave users with no way to understand what happened or what they can still do. ISO 25010 reliability.fault-tolerance expects partial operation: a profile page should still show the edit form even if the user data fetch fails; a dashboard should still show navigation even if a widget's data source is unavailable. Applications that hard-fail to a blank screen or infinite spinner on any API error eliminate user agency entirely — an especially high-impact defect in payment and checkout flows.

Separate required data (block render) from optional data (degrade gracefully). For optional API calls, always return a typed fallback on failure so the page can render partially.

// lib/api.ts — safe fetch helper
export async function safeFetch<T>(
  url: string,
  fallback: T
): Promise<T> {
  try {
    const res = await fetch(url)
    if (!res.ok) return fallback
    return res.json() as Promise<T>
  } catch {
    return fallback
  }
}

// Usage:
const widgets = await safeFetch('/api/dashboard/widgets', [])
// Page renders even if widgets is []

For required data that must succeed (e.g., auth session), let the error propagate to the nearest error boundary rather than swallowing it.