agentleFS
gongyijie85gongyijie85/dsh-ecc/skills/nuxt4-patterns/SKILL.md

nuxt4-patterns

Skill8 starsChanged 3 months agoMITView on GitHub

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.

10 other projects use a version of this, 10 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use openclaw-persona-forge.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • TironFoxSkill

    openclaw-persona-forge

    为 OpenClaw AI Agent 锻造完整的龙虾灵魂方案。根据用户偏好或随机抽卡, 输出身份定位、灵魂描述(SOUL.md)、角色化底线规则、名字和头像生图提示词。 如当前环境提供已审核的生图 skill,可自动生成统一风格头像图片。 当用户需要创建、设计或定制 OpenClaw 龙虾灵魂时使用。 不适用于:微调已有 SOUL.md、非 OpenClaw 平台的角色设计、纯工具型无性格 Agent。 触发词:龙虾灵魂、虾魂、OpenClaw 灵魂、养虾灵魂、龙虾角色、龙虾定位、 龙虾剧本杀角色、龙虾游戏角色、龙虾 NPC、龙虾性格、龙虾背景故事、 lobster soul、lobster character、抽卡、随机龙虾、龙虾 SOUL、gacha。

    Also in 5 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

15 rules. 2 are common, 0 are distinctive, and 13 are very specific to this project.

  • 2

    Common

    Most of the 10 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 13

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Common:

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

    line 10
  2. Very specific:

    Keep the first render deterministic.

    line 22
  3. Very specific:

    Use Nuxt's useRoute() composable, not the one from vue-router.

    line 24
  4. Very specific:

    Do not use route.fullPath to drive SSR-rendered markup.

    line 25
  5. Very specific:

    Treat ssr: false as an escape hatch for truly browser-only areas, not a default fix for mismatches.

    line 26
  6. Very specific:

    Prefer await useFetch() for SSR-safe API reads in pages and components.

    line 30
  7. Very specific:

    Use useAsyncData() when the fetcher is not a simple $fetch() call, when you need a custom key, or when you are composing multiple async …

    line 31
  8. Very specific:

    Keep useAsyncData() handlers side-effect free.

    line 33
  9. Very specific:

    Use $fetch() for user-triggered writes or client-only actions, not top-level page data that should be hydrated from SSR.

    line 34
  10. Very specific:

    Use lazy: true, useLazyFetch(), or useLazyAsyncData() for non-critical data that should not block navigation.

    line 35
  11. Very specific:

    Use server: false only for data that is not needed for SEO or the first paint.

    line 36
  12. Very specific:

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

    line 55
  13. Very specific:

    Use the Lazy prefix to dynamically import non-critical components.

    line 80
  14. Common:

    Use lazy hydration for below-the-fold or non-critical interactive UI.

    line 82
  15. Very specific:

    Use NuxtLink for internal navigation so Nuxt can prefetch route components and generated payloads.

    line 93

“Common” is measured: kept by at least 6 in 10 of the 10 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.