| name | web-rules |
| description | Strict design and UX rules for React 19 + Next.js 16 (App Router) + Tailwind CSS 4. Covers navigation, interaction design, accessibility, user feedback, UX patterns, and visual design. Use when designing, building, or reviewing any user-facing web feature on this stack. Trigger when the user asks to "build a settings page", "add a dialog", "design this form", "review for accessibility", "fix dark mode", or any Next.js App Router / React 19 / Tailwind UI task. Also trigger when the user says output "looks off", "isn't accessible", or "doesn't follow best practices." |
React 19 + Next.js 16 + Tailwind CSS Best Practices
Comprehensive strict-rules reference for web apps built on React 19, the Next.js 16 App Router, and Tailwind CSS 4. Contains 34 rules across 6 categories. Each rule is stated as an Always/Never directive with a quantified impact, an incorrect example, and a correct example.
Stack Contract
All guidance assumes:
- React 19 with Server Components by default; Client Components only when interactivity is required (
'use client' at the top)
- Next.js 16 App Router with
app/ directory, layout.tsx, page.tsx, loading.tsx, error.tsx, not-found.tsx, parallel routes, intercepting routes
- Server Actions for mutations (
'use server') — never useEffect for data fetching
- Tailwind CSS 4 with the
@theme directive, dark: variant, container queries, and the standard 4pt spacing scale
- lucide-react as the canonical icon system
- No CSS-in-JS (no styled-components, no emotion) — Tailwind utility classes only, with
cn() from clsx + tailwind-merge for conditional classes
- shadcn/ui primitives (Radix-based) preferred for dialogs, popovers, dropdowns, tooltips, toasts
When to Apply
Reference these rules when:
- Building any user-facing route, layout, or component
- Reviewing PRs for design / UX / accessibility regressions
- Choosing between modality types (dialog vs popover vs full-page)
- Implementing forms with Server Actions and
useFormState / useOptimistic
- Configuring loading and error boundaries
- Designing onboarding, permissions, or settings flows
- Ensuring dark mode, focus management, and keyboard navigation work end-to-end
Rule Categories by Priority
| Priority | Category | Impact | Prefix |
|---|
| 1 | Navigation | CRITICAL | nav- |
| 2 | Interaction Design | CRITICAL | inter- |
| 3 | Accessibility | CRITICAL | acc- |
| 4 | User Feedback | HIGH | feed- |
| 5 | UX Patterns | HIGH | ux- |
| 6 | Visual Design | HIGH | vis- |
Quick Reference
1. Navigation (CRITICAL)
nav-primary - Use top nav (3-7 sections) or sidebar; never hamburger-only on desktop
nav-app-router - Use App Router layouts, parallel routes, and <Link> for all internal navigation
nav-page-actions - Place primary actions in the page header; never bury them in scroll
2. Interaction Design (CRITICAL)
3. Accessibility (CRITICAL)
4. User Feedback (HIGH)
5. UX Patterns (HIGH)
ux-onboarding - Onboarding never exceeds 3 screens; always skippable
ux-permissions - Request browser permissions in-context, not on page load
ux-modality - Choose dialog / popover / full-page by content weight; never stack modals
ux-destructive-confirmation - Destructive actions require a typed confirmation OR an undo window
ux-data-entry - Use Server Actions + progressive enhancement; never disable submit while typing
ux-undo - Prefer undo over confirmation for everyday actions
ux-settings - Settings are autosaved on change; never gated behind a Save button
6. Visual Design (HIGH)
vis-dark-mode - Use CSS custom properties + dark: variant; never hardcode text-black/bg-white
vis-icon-system - Use lucide-react with 1.5px stroke and size-4/size-5 standard sizes
vis-spacing - Use the Tailwind 4 pt scale and container queries; never use ad-hoc px margins
How to Use
Read individual reference files for detailed explanations and code examples:
Reference Files