Should computed track nested refs?

[illusionaries]

related: #7873, #6994

I found nesting a ref inside a computed pretty helpful when building my blog:

1. All pages got injected at app level
2. Create a computed that takes the current route and finds the corresponding page page: Promise<Page>, then use defineAsyncComponent to load it.
   The Page type is something like:

   type Page = {
     default: never;
     __outline: string[];
   };

3. Some data, e.g. the article outline, is exported by the page module, and won't be available until the promise is resolved, so I used a ref which is initially null, and will be updated with page.then(x => outline.value = x.__outline).
4. The computed is something like

   const data = computed(() => {
     const pageModule = modules[route.path]() as Promise<Page>;
     const pageComponent = defineAsyncComponent(() => pageModule);
     const outline = ref<string[] | null>(null);
     pageModule.then((x) => (outline.value = x.__outline));
     return {
       component: pageComponent,
       outline,
     };
   });

As mentioned in #7873 and #6994, this is not the intended usage of the api, but i found it quit useful, and is working as intended on the client side. A minimal reproduction is at https://stackblitz.com/github/illusionaries/ssr-computed, I will also paste the core code here:

<script setup lang="ts">
import { computed, onMounted, onServerPrefetch, ref } from "vue";

const foo = computed(() => {
  console.log("executing computed");
  let num = ref(0);
  const modifyPromise = new Promise<void>((resolve) => {
    setTimeout(() => {
      num.value++;
      resolve();
    }, 1000);
  });
  return {
    num,
    modifyPromise,
  };
});

onServerPrefetch(() => foo.value.modifyPromise);

onMounted(async () => {
  await foo.value.modifyPromise;
});
</script>
<template>
  <span>{{ foo.num }}</span>
</template>

But I noticed some inconsistencies between client build and SSR build, even between different versions of vue.

On the client side, regardless of the version, the computed is executed only once, and num is updated from 0 to 1 after 1 second, which is expected.

On the SSR side, with vue latest (3.5.28), the computed got executed twice, and the rendered result is <span data-v-8338d79c>0</span>. But with vue 3.6 beta (actually, just override "@vue/runtime-core": "beta" is enough), the computed got executed only once, and the rendered result is <span data-v-8338d79c>1</span>.

I haven't dug into the source code yet, but I suppose it has something to do with the computed tracking the internally created ref (at least, the VSCode extension highlights the internal ref as a dependency). On the server side, changing the internal ref value caused the computed to evaluate, replacing the foo.num with 0 again. But somehow on the client side, the ref change does not trigger an re-evaluation.

Is the inconsistency expected or is it actually a bug? If it's expected, is there any recommended way to achieve the same effect without nesting a ref inside a computed?

I have tried to use defineExpose in the page component to expose the outline, but template ref does not work with SSR as far as I know, because the component instance is not created on the server side and useTemplateRef always returns null.

[aniruddhaadak80]

@aeharding Computed properties automatically unwrap top-level refs, but they do NOT deeply unwrap refs nested inside standard objects returned by the computed.
This is by design (to avoid expensive deep traversal).
If you return { component, outline } where outline is a ref, the consumer needs to access computed.value.outline.value.
To make it cleaner, unwrap it in the computed:

return {
  component,
  outline: outline.value
}

[illusionaries]

Thanks for your reply. The problem is that component is an async component, and hasn't been resolved when returned. Thus, outline.value at this point is just null. I would like to resolve outline after the async component resolution (after the value was returned), wrapping it inside a ref is the only idea I can come up of. Unwrapping it in the computed seems to cause the loss of reactivity.

[GitNimay]

I would not rely on this pattern. A computed getter should be pure: it should derive and return a value from existing reactive state, not create new refs, start promises, or mutate state later from inside the getter.

In your example, the getter does all three:

const foo = computed(() => {
  const num = ref(0);

  const modifyPromise = new Promise<void>((resolve) => {
    setTimeout(() => {
      num.value++;
      resolve();
    }, 1000);
  });

  return {
    num,
    modifyPromise,
  };
});

That makes the result dependent on when Vue decides to evaluate or re evaluate the computed. In SSR this is especially fragile because server rendering, onServerPrefetch, async dependency resolution, and template rendering can touch the computed at different times. So I would treat the difference between 3.5 and 3.6 beta as an implementation detail exposed by unsupported usage, not as something application code should depend on.

A safer shape is to make the state stable outside the computed, and use watch or watchEffect for the async side effect:

const outline = ref<string[] | null>(null);
const component = shallowRef<Component | null>(null);
const pending = shallowRef<Promise<void> | null>(null);

watchEffect(() => {
  const pageModule = modules[route.path]() as Promise<Page>;

  component.value = defineAsyncComponent(() => pageModule);

  pending.value = pageModule.then((page) => {
    outline.value = page.__outline;
  });
});

onServerPrefetch(async () => {
  await pending.value;
});

Or return a single resolved page data object from an async loader and derive from that:

const page = shallowRef<Page | null>(null);

async function loadPage(path: string) {
  page.value = await modules[path]();
}

watch(
  () => route.path,
  (path) => {
    void loadPage(path);
  },
  { immediate: true },
);

onServerPrefetch(async () => {
  await loadPage(route.path);
});

const outline = computed(() => page.value?.__outline ?? null);
const component = computed(() =>
  page.value
    ? defineAsyncComponent(() => Promise.resolve(page.value!))
    : null,
);

The key point is that the ref identity should be stable. The computed can read page, outline, or route.path, but it should not create a new ref and then rely on async code mutating that ref later.

For your blog use case, I would model it as “route selects a page module, loader resolves the module, computed values read the resolved module.” That gives SSR a concrete promise to wait for and avoids depending on nested refs inside a computed return value.

So my answer would be: the inconsistency is not something I would depend on or design around. The recommended fix is to move the async work and mutable refs out of the computed, then use watch plus onServerPrefetch to populate stable state.

[illusionaries]

You're right. Actually my original code was implemented with watch and a bunch of refs, and I later refactored it to use a single computed, hoping to make the code look cleaner. This introduced the weird nested refs. Should have stuck with watch in the first place...

[GitNimay]

Glad that help👍

[aymenhmaidiwastaken]

This is not a bug you should design around — it's undefined behavior being exposed by an unsupported pattern.

A computed getter should be pure: derive a value from existing reactive state, return it. Your getter creates a new ref, starts a setTimeout, and mutates that ref asynchronously — all inside the computed. That breaks the contract.

Why it behaves differently in SSR vs client:

When the inner ref is created inside the computed, Vue's reactivity system may or may not track it as a dependency of that computed. If it does track it, then when num.value++ fires, Vue re-evaluates the computed, creating a new ref(0) — resetting num back to 0. The SSR renderer and client runtime have different evaluation timing, which is why you see different results between them (and between Vue versions).

The difference between 3.5 and 3.6 beta is an internal implementation detail, not a fix.

The fix — move async work and mutable state out of the computed:

const outline = ref<string[] | null>(null);
const component = shallowRef<Component | null>(null);
const loadPromise = shallowRef<Promise<void>>();

watchEffect(() => {
  const pageModule = modules[route.path]() as Promise<Page>;
  component.value = defineAsyncComponent(() => pageModule);
  loadPromise.value = pageModule.then((page) => {
    outline.value = page.__outline;
  });
});

onServerPrefetch(() => loadPromise.value);

This way:

• ref identities are stable (created once, not inside a computed)
• The watchEffect re-runs when route.path changes
• SSR has a concrete promise to await via onServerPrefetch
• No reliance on nested ref tracking behavior

For your blog, model it as: route selects module → loader resolves it → computed reads the resolved data. Keep the async and the reactive state separate.