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] and state are established above, returning state as Ref<T> is sufficient. The computed fallback to nuxtApp.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 to state.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 for InitOption<T> (a function type). This naming can mislead users and maintainers.

Consider either:

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

Apply this diff to use InitOption<T> directly:

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

Then replace UseStateOptions<T> with InitOption<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 if args[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.

The as Ref<T> assertion reconciles two overloads that declare different return types (Ref<UnwrapRef<T>> vs Ref<T>). Whilst the runtime behaviour is correct (values are unwrapped via toValue), 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.

When reset is true and nuxtApp._state[key] exists, the code performs two assignments:

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

Since _state[key].data is a toRef to payload.state[key] (created on line 36/38), they reference the same underlying value. The assignment on line 71 may cause an intermediate undefined 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 and reset 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 calls toValue(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 the toValue 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 assertion as [unknown, InitOption<T>] bypasses TypeScript's type checking. Given the complex autoKey logic above, this could mask runtime errors if args 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 ensure args matches the expected structure before destructuring.

---

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

The console.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