packages/nuxt/src/app/nuxt.ts (1)

145-151:Internal _state map looks good; consider GC of stale keys

The addition is well‑typed and initialised correctly. To avoid long‑lived growth on the client, consider pruning entries (e.g. delete nuxtApp._state[key]) when a state is cleared without reset and no watchers remain. This keeps memory proportional to active state keys.

Also applies to: 319-319

packages/nuxt/src/app/composables/state.ts (1)

45-56:You can simplify to a plain ref; computed indirection is unnecessary

Given_state[key] andstate are established above, returningstate as Ref<T> is sufficient. The computed fallback tonuxtApp.payload.state[key] is dead code in this path and adds overhead.

Apply:

-  return computed({-    get () {-      return nuxtApp._state[key]?.data.value ?? nuxtApp.payload.state[key]-    },-    set (value) {-      if (nuxtApp._state[key]) {-        nuxtApp._state[key]!.data.value = value-      } else {-        nuxtApp.payload.state[key] = value-      }-    },-  })+  return state as Ref<T>

If you keep the computed, consider at least collapsing the branches tostate.value for both get/set. As per coding guidelines.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

packages/nuxt/src/app/composables/state.ts (5)

9-10:Simplify type alias or rename to avoid confusion.

UseStateOptions<T> suggests an options object with multiple properties, but it's merely an alias forInitOption<T> (a function type). This naming can mislead users and maintainers.

Consider either:

• UsingInitOption<T> directly throughout, or
• Renaming toUseStateInit<T> to reflect that it's a single init function rather than a structured options object.

Apply this diff to useInitOption<T> directly:

-type InitOption<T> = (() => MaybeRefOrGetter<T>)-type UseStateOptions<T> = InitOption<T>+type InitOption<T> = () => MaybeRefOrGetter<T>

Then replaceUseStateOptions<T> withInitOption<T> on lines 18, 19, and 25.

---

21-24:Clarify the autoKey handling logic.

The autoKey extraction and re‑insertion logic is difficult to follow. The code pops the last argument if it's a string, then conditionally unshifts it back ifargs[0] is not a string. This approach is fragile and not immediately clear to maintainers.

Consider refactoring for clarity, or at minimum add inline comments explaining the intended argument patterns (e.g.,(key, init),(init),(key), etc.) and how this logic resolves them.

---

45-45:Type assertion bypasses overload return‑type differences.

Theas Ref<T> assertion reconciles two overloads that declare different return types (Ref<UnwrapRef<T>> vsRef<T>). Whilst the runtime behaviour is correct (values are unwrapped viatoValue), this assertion may obscure type‑checking issues and could lead to subtle inference problems for callers.

If the inconsistency (flagged earlier) is intentional, consider documenting why the types differ; otherwise, unify the return types to eliminate the need for this assertion.

---

69-77:Potential redundancy and intermediate state flicker when resetting.

Whenreset is true andnuxtApp._state[key] exists, the code performs two assignments:

1. Line 71 setsnuxtApp.payload.state[key] = undefined (directly on the object)
2. Line 75 setsnuxtApp._state[key]!.data.value = toValue(...) (through the ref)

Since_state[key].data is atoRef topayload.state[key] (created on line 36/38), they reference the same underlying value. The assignment on line 71 may cause an intermediateundefined state before line 75 overwrites it with the default, potentially triggering watchers or causing a visual flicker.

Consider skipping the line 71 assignment when_state[key] exists andreset is true, or reordering to set the reset value first.

Apply this diff to avoid the intermediate state:

 function clearNuxtStateByKey (nuxtApp: NuxtApp, key: string, reset: boolean): void {-  if (key in nuxtApp.payload.state) {-    nuxtApp.payload.state[key] = undefined-  }-   if (nuxtApp._state[key]) {     nuxtApp._state[key]!.data.value = reset ? toValue(nuxtApp._state[key]!._default) : undefined+  } else if (key in nuxtApp.payload.state) {+    // Clear legacy state entries that lack _state registry+    nuxtApp.payload.state[key] = undefined   } }

---

41-43:Consider error handling for init function execution.

The code callstoValue(defaultFn) (line 42) without catching potential errors. If the init function throws during initial hydration or reset, the exception will propagate and could break the component or app.

Consider wrapping thetoValue call (here and on line 75) in a try‑catch to provide a more helpful error message or graceful fallback.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

docs/4.api/3.utils/clear-nuxt-state.md (1)

12-14:Improve sentence structure for clarity.

The phrase "initial value passing a second parameter" is grammatically awkward. Consider adding a comma or rephrasing for better readability.

Apply this diff to improve the grammar:

-You can also reset the state to the initial value passing a second parameter+You can also reset the state to the initial value by passing a second parameter

packages/nuxt/src/app/composables/state.ts (2)

25-25:Consider stronger type safety for the destructuring.

The type assertionas [unknown, InitOption<T>] bypasses TypeScript's type checking. Given the complex autoKey logic above, this could mask runtime errors ifargs doesn't have the expected shape.

Consider either:

1. Simplifying the argument handling logic to make the types provable, or
2. Adding runtime validation to ensureargs matches the expected structure before destructuring.

---

82-89:Consider using Nuxt's logger instead of console.error.

Theconsole.error on line 86 logs errors directly to the console. For consistency with Nuxt's logging patterns and better control in production environments, consider using a Nuxt logger utility if available.

This is a minor suggestion since the error case (init function throwing) should be rare.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro