Skip to content
cccskills
FreePublished on GitHubEnglish overview

nuxt4-patterns

Build and review Nuxt 4 applications with consistent server and browser rendering. Guide data fetching, page rendering and caching rules, and deferred loading to address rendering mismatches and improve performance.

OriginalShow the original description

Nuxt 4 app patterns for hydration safety, performance, route rules, lazy loading, and SSR-safe data fetching with useFetch and useAsyncData. Use when building or reviewing a Nuxt 4 app, or debugging hydration mismatches and SSR-safe data fetching.

AI rating100/ 100See how to install

Good for

  • Debugging differences between server and browser rendering
  • Reviewing page data fetching with useFetch and useAsyncData
  • Choosing rendering and caching rules for each route group
  • Deferring nonessential components and data loading

Overview

What it does

Reviews rendering mismatches and data fetching in Nuxt 4 applications, and helps choose rendering and caching policies that fit each page. It checks the initial display and placement of browser-only code to prevent hydration mismatches. Hydration is the process of connecting browser-side behavior to a page generated on the server. The skill also covers choosing between useFetch and useAsyncData, and deferring data or components that are not needed immediately.

When it helps

Use it when developing or reviewing an application that uses server-side rendering (SSR). It helps when article or product pages need a different rendering approach from administration screens. It also applies when data fetching blocks page navigation or heavy interface components need attention.

Example requests

  • "Investigate this Nuxt 4 rendering mismatch and make the initial server and browser displays agree."
  • "Organize routeRules for article pages and administration screens."
  • "Defer components and data that the initial display does not need."

Notes

These guidelines target Nuxt 4. Incremental static regeneration (ISR), which regenerates static pages incrementally, requires a supported hosting platform. Lazy hydration applies to single-file components; passing new props starts hydration immediately.

This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.

Objective evaluation

AI rated this skill on four points using only the contents of its SKILL.md. Stars and popularity are not taken into account.

Clear instructionsIs it clear when to use it and what it does?
AGoodIt explicitly identifies Nuxt 4 use cases involving hydration mismatches, data fetching, and rendering strategies.
Concrete stepsAre steps, inputs, outputs, and examples spelled out?
AGoodIt includes code examples for `useAsyncData`, `routeRules`, and lazy loading, plus a review checklist.
SafetyAre sending data, deleting files, and running commands disclosed?
AGoodIt specifies no deletion or credential operations and instructs keeping data fetching handlers free of side effects.
Easy setupDoes it need few tools or API keys, and are they documented?
AGoodIt specifies Nuxt 4, requires no additional services, and states that ISR needs a supported platform.

The total counts each point as A = 25, B = 15, C = 5. Rated by AI (OpenAI Codex) as of Oct 19, 2026. Treat it as a guide and read the original before installing.

Disagree? Request a re-evaluation

Tell us which point is wrong and why. No login needed. We will check it against the SKILL.md, redo the evaluation, and show the result here.

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

Files included (1)

  • SKILL.md4.6 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Nuxt 4 Patterns

Use when building or debugging Nuxt 4 apps with SSR, hybrid rendering, route rules, or page-level data fetching.

When to Activate

  • Hydration mismatches between server HTML and client state
  • Route-level rendering decisions such as prerender, SWR, ISR, or client-only sections
  • Performance work around lazy loading, lazy hydration, or payload size
  • Page or component data fetching with useFetch, useAsyncData, or $fetch
  • Nuxt routing issues tied to route params, middleware, or SSR/client differences

Hydration Safety

  • Keep the first render deterministic. Do not put Date.now(), Math.random(), browser-only APIs, or storage reads directly into SSR-rendered template state.
  • Move browser-only logic behind onMounted(), import.meta.client, ClientOnly, or a .client.vue component when the server cannot produce the same markup.
  • Use Nuxt's useRoute() composable, not the one from vue-router.
  • Do not use route.fullPath to drive SSR-rendered markup. URL fragments are client-only, which can create hydration mismatches.
  • Treat ssr: false as an escape hatch for truly browser-only areas, not a default fix for mismatches.

Data Fetching

  • Prefer await useFetch() for SSR-safe API reads in pages and components. It forwards server-fetched data into the Nuxt payload and avoids a second fetch on hydration.
  • Use useAsyncData() when the fetcher is not a simple $fetch() call, when you need a custom key, or when you are composing multiple async sources.
  • Give useAsyncData() a stable key for cache reuse and predictable refresh behavior.
  • Keep useAsyncData() handlers side-effect free. They can run during SSR and hydration.
  • Use $fetch() for user-triggered writes or client-only actions, not top-level page data that should be hydrated from SSR.
  • Use lazy: true, useLazyFetch(), or useLazyAsyncData() for non-critical data that should not block navigation. Handle status === 'pending' in the UI.
  • Use server: false only for data that is not needed for SEO or the first paint.
  • Trim payload size with pick and prefer shallower payloads when deep reactivity is unnecessary.
const route = useRoute()

const { data: article, status, error, refresh } = await useAsyncData(
  () => `article:${route.params.slug}`,
  () => $fetch(`/api/articles/${route.params.slug}`),
)

const { data: comments } = await useFetch(`/api/articles/${route.params.slug}/comments`, {
  lazy: true,
  server: false,
})

Route Rules

Prefer routeRules in nuxt.config.ts for rendering and caching strategy:

export default defineNuxtConfig({
  routeRules: {
    '/': { prerender: true },
    '/products/**': { swr: 3600 },
    '/blog/**': { isr: true },
    '/admin/**': { ssr: false },
    '/api/**': { cache: { maxAge: 60 * 60 } },
  },
})
  • prerender: static HTML at build time
  • swr: serve cached content and revalidate in the background
  • isr: incremental static regeneration on supported platforms
  • ssr: false: client-rendered route
  • cache or redirect: Nitro-level response behavior

Pick route rules per route group, not globally. Marketing pages, catalogs, dashboards, and APIs usually need different strategies.

Lazy Loading and Performance

  • Nuxt already code-splits pages by route. Keep route boundaries meaningful before micro-optimizing component splits.
  • Use the Lazy prefix to dynamically import non-critical components.
  • Conditionally render lazy components with v-if so the chunk is not loaded until the UI actually needs it.
  • Use lazy hydration for below-the-fold or non-critical interactive UI.
<template>
  <LazyRecommendations v-if="showRecommendations" />
  <LazyProductGallery hydrate-on-visible />
</template>
  • For custom strategies, use defineLazyHydrationComponent() with a visibility or idle strategy.
  • Nuxt lazy hydration works on single-file components. Passing new props to a lazily hydrated component will trigger hydration immediately.
  • Use NuxtLink for internal navigation so Nuxt can prefetch route components and generated payloads.

Review Checklist

  • First SSR render and hydrated client render produce the same markup
  • Page data uses useFetch or useAsyncData, not top-level $fetch
  • Non-critical data is lazy and has explicit loading UI
  • Route rules match the page's SEO and freshness requirements
  • Heavy interactive islands are lazy-loaded or lazily hydrated

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

accessibility

FreeSummaryAI rating 100

Design and audit interfaces for Web, iOS, and Android using WCAG 2.2 accessibility guidance. Check screen-reader labels, keyboard navigation, contrast, and control sizes to identify barriers and guide implementation for people using assistive technology.

  • Adding descriptive labels to icon-only buttons
  • Reviewing keyboard navigation and modal focus
  • Checking contrast and control sizes
affaan-m/ECC283.7KUpdated Oct 16, 2026

agent-architecture-audit

FreeSummaryAI rating 80

Investigate unreliable AI agents across 12 layers, including instructions, memory, tool execution, and display. Use code and logs to trace failures, rank findings by severity, and produce an ordered repair plan that prioritizes code changes.

  • Investigating failures that appear only inside an agent application
  • Tracing old conversation content leaking into new sessions
  • Checking skipped or falsely claimed tool execution
affaan-m/ECC283.7KUpdated Oct 16, 2026

agent-eval

FreeSummaryAI rating 80

Compare coding agents on tasks from your own codebase. Define success checks, run agents in separate Git working directories, and report pass rates, available API costs, completion time, and consistency across repeated trials.

  • Comparing coding agents on real development tasks
  • Evaluating a new tool or model before adoption
  • Checking performance after agent updates
affaan-m/ECC283.7KUpdated Oct 16, 2026

agent-harness-construction

FreeSummaryAI rating 100

Design and refine an AI agent’s available actions, tool inputs, and result formats. Define recovery steps for errors, manage the information kept in context, and evaluate changes through completion rates, retries, and cost per successful task.

  • Define an AI agent’s tool set and input formats
  • Make tool results and next steps easier to interpret
  • Specify safe retries and stopping conditions
affaan-m/ECC283.7KUpdated Oct 16, 2026

agent-introspection-debugging

FreeSummaryAI rating 100

Diagnose failed AI agent runs by capturing errors, checking likely causes, and choosing small, reversible recovery actions. The workflow produces a structured report of the failure, recovery steps, and evidence, helping explain repeated retries or stalled progress.

  • Diagnosing repeated tool calls with no progress
  • Investigating quality loss as context grows
  • Checking file paths and environment mismatches
affaan-m/ECC283.7KUpdated Oct 16, 2026

agent-introspection-debugging

FreeSummaryAI rating 100

Diagnose AI agent runs that fail repeatedly, loop through tools, or lose track of the task. Capture errors and environment details, test a focused recovery action, and produce a report explaining the evidence and outcome.

  • Diagnosing repeated failures in an agent run
  • Investigating loops through the same tool calls
  • Reviewing output degradation as context grows
affaan-m/ECC283.7KUpdated Oct 5, 2026

See all skills by affaan-m

Report a problem with this skill