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