Add signal API Design to reactivity

[teleskop150750]

Untrack

When used inside a watchEffect or computed, any state read inside fn will not be treated as a dependency.

watchEffect(() => {
  // this will run when `a` changes, but not when `b` changes
  console.log(a.value, untrack(() => b.value))
});

function untrack<T>(fn: () => T): T;

Like solid, svelte, preact, angular

Signal

It would be very useful to see a signals API similar to the implementation in solid.
Or implement explicit methods for inserting and getting the value

const [count, setCount] = createSignal(0)

The Problem

Readonly signal

Many libraries were forced to use readonly(), which hurts performance, or find other ways. Explicitly separating getters and setters fixes this complexity.

Example: TanStack query discussions

More flexible signal update

When updating a signal based on its previous value, the code for getting it is called first, then the new value is set. In this case, the signal is added to the effect's dependency list.

// ref api
const count = shallowRef(0)

watchEffect(() => {
  foo.value;
  count.value +=1
})

// signal api
const [count, setCount] = createSignal(0)

watchEffect(() => {
  foo();
  // oldValue => raw old value
  setCount((oldValue) => oldValue + 1)
})

Better Dx for writing composables

Often, passing and updating reactive variables in composables requires additionally wrapping them in functions.

If such methods were initially available, this would not be necessary

export interface UseFooOption {
    count: () => number
    bar: () => number
    change: (count: number) => void
}

export function useFoo(options: UseFooOption) {
  // ....
}

const count = shallowRef(1)

const foo = useFoo({
    count: () => count.value,
    change: (v) => {count.value = v},
    bar: () => props.bar
})

Simplifying MaybeRefOrGetter

Currently, it is a popular practice to process 3 different parameters: Ref, Function, non-ref variable.
For this, the helpers type MaybeRefOrGetter and toValue have been added.

Example vueuse

Thanks to the signals API, we have two types of data for options in composable objects.

export interface UseBarOption {
    timeoutOpen: (() => number) | number
}

// For constants
const bar = useBar({
    timeoutOpen: props.bar,
})

// For dynamic data
const bar = useBar({
    timeoutOpen: () => props.bar,
})

a new api could popularize this method

[jods4]

Someone has created a discussion dedicated to untrack / peek (read without tracking) here:
#750

I've commented there that Vue provides the primitives to create that function today if you want to, and I agree it would be a nice addition to Vue core (and more efficient).
I think the poster child use-case is wanting to increment a counter inside a watch, without having a dependency on that counter itself. I have encountered similar situations myself as well.

When it comes to Signal-like apis (pairs of getter/setter functions), I feel like this is a matter of style, different frameworks have taken different approaches -- and none is strictly better in all aspects.
I'd guess most people in Vue community like being able to write ticks.value++ instead of setTicks(ticks() + 1).
On the other hand, yes, there are situations when having a pair of functions is convient. Trade-offs.

Thing is, Vue is a mature framework with many users, and large projects in production. So refs are not going anywhere.
Adding signals is yet another way to do things, it creates confusion and complexity.
As Signals don't enable new scenarios -- in fact you can create them on top of Vue core today if you'd like -- I don't think they're a good candidate for inclusion in Core.

[leopiccionia]

Just for curiosity: the docs evens show how to create Solid-like and Angular-like signals in Vue.

[teleskop150750]

@leopiccionia Example: Implementation based on current api

@jods4

Adding signals is yet another way to do things, it creates confusion and complexity.

Adding new ways to solve the same problems has never been a problem for Vue 😊)). useTemplateRef, useModel, useSlots, defineSlots

[teleskop150750]

@jods4
Unfortunately, library developers and authors are unlikely to want to develop and impose their own implementations of the reactivity api.

In my opinion, the current api provokes passing refs as parameters, instead of explicitly declaring methods for receiving and updating.
This makes the code less clean and may be more difficult to maintain.

An example from the documentation on working with reactivity
(Even here, the documentation recommends using readonly for ref)

https://vuejs.org/guide/components/provide-inject.html#working-with-reactivity

VueUse
vueuse/vueuse#1768

It seems to me that this is one of the reasons for the complex vue-query code. In it, they are forced to manually check each parameter for isRef.

https://github.com/TanStack/query/blob/e474f7340c6497745c9feef27a3a66717506c007/packages/vue-query/src/utils.ts#L70

Pinia-colada suggests using the function or MaybeRefOrGetter

https://pinia-colada.esm.dev/cookbook/migration-tvq.html#Using-ref-and-computed-in-queryKey

It's a little disappointing that initially the update/get methods existed, but for some reason they were hidden in get/set.
This adds magic to the code, and limits control. Now, to get this functionality back, I have to write additional code and create wrappers every time.

You say that many users like to use the current api. Perhaps they just didn't have the opportunity to compare other options))). I don't see an advantage in writing console.log(foo.value) rather than console.log(foo.get()). I partially explain the current api to myself by compatibility with vue 2 and automatic unref variables in tempalte, but this also has its drawbacks (https://x.com/teleskop150750/status/1878908961153572887 ) and poor typescript support in the early stages of vue

https://github.com/vuejs/core/blob/604d08760ee5b01772bc33cefd89ebdca9bb1b82/packages/reactivity/src/ref.ts#L266-L280

https://github.com/vuejs/core/blob/604d08760ee5b01772bc33cefd89ebdca9bb1b82/packages/runtime-core/src/component.ts#L1185

Adding signals is yet another way to do things, it creates confusion and complexity.

For me, on the contrary, it's reducing the number of options from MaybeRefOrGetter to MaybeGetter or Getter.

My suggestion is to fix the problem in the kernel, rather than additional utilities that increase complexity.