Version

3.0.0-rc.10

Reproduction link

https://github.com/an-sh/standalone-computed-test

Steps to reproduce

Create a singleton class with ref and computed properties inside component's setup.

Use a singleton instance in a component that goes through several mount/unmount cycles.

What is expected?

ref and computed properties should behave the same way

What is actually happening?

Ref property stays reactive for all component instances , however a computed property will stop being reactive after the first component instance is unmounted.

Not sure what exactly should happen, it is easy to assume that anything created during a setup call should be coupled with a components life-cycle. But i don't see any options to enforce ref/computed values to be indefinitely global or be disposed at a certain point outside of components logic (like rxjs unsubscribe).

Currently, there is a binding relationship between the computed and component instance, so that computed's effect will be stopped when the component is unmounted. The singleton makes computed's effect never activate again after being stopped, maybe we need to add an option for computed(), such as global:

export interface WritableComputedOptions<T> {
  get: ComputedGetter<T>
  set: ComputedSetter<T>
  global?: boolean
}

It's false by default, when true, the users can stop it manually:

const doubleCount = computed({
  get: () => counter.value * 2,
  global: true
})
// stop it
stop(doubleCount.effect) // or directly compouted `stop(doubleCount)`

Or, we provide a globalComputed() function:

const doubleCount = globalComputed(() => counter.value * 2)
stop(doubleCount.effect)  // or directly compouted `stop(doubleCount)`

Duplicate of https://github.com/vuejs/vue-next/issues/1532

@HcySunYang I think it's worth posting that comment on the other issue. It has useful information.

On Sun, 2020-09-06 at 01:05 -0700, Eduardo San Martin Morote wrote:

Closed #2057.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

Looks like this one is a partial duplicate, it doesn't cover a case with a different standalone ref behaviour. Even if an additional global or a manual clean-up option is implemented, it doesn't cover why ref is still being active after a component was unmounted. Depending on a reactivity implementation, it may cause a leak. My guess would be that a standalone ref should behave the same way as a computed prop or watch case described in #1532, with the same additional setup to explicitly indicate that it not a part of a current component lifecycle. Or if it is not the case, hopefully the guide will be updated.