Frontend Beauty
ESC

Type to search the knowledge base.

Loading and Error UI Files

loading.tsx and error.tsx create Instant Suspense and error boundaries per route segment in the App Router.

beginner3 min read
  • nextjs
  • loading-and

Special files give you loading and error UX without hand-wiring every boundary. loading.tsx wraps a segment in Suspense. error.tsx is a Client Component error boundary for that segment.

Docs: Loading UI, Error Handling.

loading.tsx

// app/dashboard/loading.tsx
export default function Loading() {
  return <p>Loading dashboard…</p>;
}

While the segment’s page (or deeper server work) suspends, users see this fallback. Nested loading.tsx files create nested boundaries so a slow child does not block a fast sibling layout.

error.tsx

// app/dashboard/error.tsx
'use client';

export default function Error({
  error,
  reset,
}: {
  error: Error & { digest?: string };
  reset: () => void;
}) {
  return (
    <div role="alert">
      <h2>Something went wrong</h2>
      <button type="button" onClick={reset}>Try again</button>
    </div>
  );
}

Must be a Client Component. reset re-renders the segment. Errors bubble to the nearest error.tsx. The root layout needs global-error.tsx for errors in the root layout itself.

not-found

import { notFound } from 'next/navigation';
if (!item) notFound();

Triggers not-found.tsx for that segment tree.

Composition tips

  • Put skeletons in loading.tsx that match layout to reduce CLS.
  • Log error.digest in production monitoring.
  • Do not swallow auth errors in UI-only boundaries — handle redirects in Server Components / middleware intentionally.

Interview out-loud

“loading.tsx creates a Suspense boundary for a route segment; error.tsx is a client error boundary with a reset function. Nested files isolate slow or failing UI so sibling chrome stays up. global-error covers the root layout.”

Further reading

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Related guides