/nextjs-code-review

name: nextjs-code-review
description: Provides comprehensive code review capability for Next.js applications, validates Server Components, Client Components, Server Actions, caching strategies, metadata, API routes, middleware, and performance patterns. Use when reviewing Next.js App Router code changes, before merging pull requests, after implementing new features, or for architecture validation. Triggers on "review Next.js code", "Next.js code review", "check my Next.js app".
allowed-tools: Read, Edit, Grep, Glob, Bash

Next.js Code Review

Overview

Evaluates Next.js App Router code against best practices for Server Components, Client Components, Server Actions, caching strategies, and production-readiness criteria. Produces actionable findings categorized by severity with concrete code examples. Delegates to `typescript-software-architect-review` agent for architectural analysis.

When to Use

• Reviewing Next.js pages, layouts, and route segments before merging
• Validating Server Component vs Client Component boundaries
• Checking Server Actions for security and correctness
• Reviewing data fetching patterns (fetch, cache, revalidation)
• Evaluating caching strategies (static generation, ISR, dynamic rendering)
• Assessing middleware implementations (authentication, redirects, rewrites)
• Reviewing API route handlers for proper request/response handling
• Validating metadata configuration for SEO
• Checking loading, error, and not-found page implementations
• After implementing new Next.js features or migrating from Pages Router

Instructions

1. **Identify Scope**: Determine which Next.js route segments and components are under review. Use `glob` to discover `page.tsx`, `layout.tsx`, `loading.tsx`, `error.tsx`, `route.ts`, and `middleware.ts` files.

2. **Analyze Component Boundaries**: Verify proper Server Component / Client Component separation. Check that `'use client'` is placed only where necessary and as deep in the component tree as possible. Ensure Server Components don't import client-only modules.

3. **Review Data Fetching**: Validate fetch patterns — check for proper `cache` and `revalidate` options, parallel data fetching with `Promise.all`, and avoidance of request waterfalls. Verify that server-side data fetching doesn't expose sensitive data to the client.

4. **Evaluate Caching Strategy**: Review static vs dynamic rendering decisions. Check `generateStaticParams` usage for static generation, `revalidatePath`/`revalidateTag` for on-demand revalidation, and proper cache headers for API routes.

5. **Assess Server Actions**: Review form actions for proper validation (both client and server-side), error handling, optimistic updates with `useOptimistic`, and security (ensure actions don't expose sensitive operations without authorization).

6. **Check Middleware**: Review middleware for proper request matching, authentication/authorization logic, response modification, and performance impact. Verify it runs only on necessary routes.

7. **Review Metadata & SEO**: Check `generateMetadata` functions, Open Graph tags, structured data, `robots.txt`, and `sitemap.xml` configurations. Verify dynamic metadata is properly implemented for pages with variable content.

8. **Validate Findings**: Before finalizing, verify each issue by checking the actual code context. Confirm the pattern violation exists, ensure the suggested fix is applicable to the codebase, and remove any false positives.

9. **Produce Review Report**: Generate a structured report with severity-classified findings (Critical, Warning, Suggestion), positive observations, and prioritized recommendations with code examples.

Examples

Example 1: Server/Client Component Boundaries

// ❌ Bad: Entire page marked as client when only a button needs interactivity
'use client';

export default async function ProductPage({ params }: { params: { id: string } }) {
  const product = await fetch(`/api/products/${params.id}`);
  return (
    <div>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      <button onClick={() => addToCart(product.id)}>Add to Cart</button>
    </div>
  );
}

// ✅ Good: Server Component with isolated Client Component
// app/products/[id]/page.tsx (Server Component)
import { AddToCartButton } from './add-to-cart-button';

export default async function ProductPage({ params }: { params: Promise<{ id: string }> }) {
  const { id } = await params;
  const product = await getProduct(id);

  return (
    <div>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      <AddToCartButton productId={product.id} />
    </div>
  );
}

// app/products/[id]/add-to-cart-button.tsx (Client Component)
'use client';

export function AddToCartButton({ productId }: { productId: string }) {
  return <button onClick={() => addToCart(productId)}>Add to Cart</button>;
}

Example 2: Data Fetching Patterns

// ❌ Bad: Sequential data fetching creates waterfall
export default async function DashboardPage() {
  const user = await getUser();
  const orders = await getOrders(user.id);
  const analytics = await getAnalytics(user.id);
  return <Dashboard user={user} orders={orders} analytics={analytics} />;
}

// ✅ Good: Parallel data fetching with proper Suspense boundaries
export default async function DashboardPage() {
  const user = await getUser();
  const [orders, analytics] = await Promise.all([
    getOrders(user.id),
    getAnalytics(user.id),
  ]);
  return <Dashboard user={user} orders={orders} analytics={analytics} />;
}

// ✅ Even better: Streaming with Suspense for independent sections
export default async function DashboardPage() {
  const user = await getUser();
  return (
    <div>
      <UserHeader user={user} />
      <Suspense fallback={<OrdersSkeleton />}>
        <OrdersSection userId={user.id} />
      </Suspense>
      <Suspense fallback={<AnalyticsSkeleton />}>
        <AnalyticsSection userId={user.id} />
      </Suspense>
    </div>