chore(reactivity): update toRef return value type

[Alfred-Skyblue]

toRef(()=>({a:1)) should return DeepReadonly, otherwise when the function returns an object or an array, modifying the object property ts will not report an error, but the modification will not be successful.

Expected:

const obj = toRef(()=>({a:1)) 
obj.value.a = 2 // Cannot assign to 'a' because it is a read-only property

console.log(obj.value.a) // 1

Actual:

const obj = toRef(()=>({a:1)) 
obj.value.a = 2 // success

console.log(obj.value.a) // 1

[skirtles-code]

Is it safe to assume that the value returned from toRef() is deep readonly? If the value that's returned is an external reactive object (which seems quite a likely scenario in practice) then there should be no problem mutating a nested property:

const a = reactive({ b: { c: { d: 7 } } })

const c = toRef(() => a.b.c)

c.value.d = 6

In this scenario, I'd expect c to behave just like a computed(), allowing the assignment of c.value.d.

Perhaps I've misunderstood the proposed change, but it looks like it would prevent this kind of assignment.

In the original example given in the PR, the object in the value isn't readonly, it's just that a new object is returned each time the value is accessed. I'm not sure whether toRef() is intended to be used that way in practice. Wouldn't using either ref() or computed() be a more 'correct' way to handle a use case like that? Returning a new object each time seems likely to cause various other problems, e.g. obj.value === obj.value will be false. I think the callback passed to toRef() is expected to be 'stable' under repeat invocations.

[LinusBorg]

I agree with @skirtles-code - this usage, while technically possible, doesn't really make sense in the context of what toRef is usually used for: getting a reactive reference to another stable value. And in that common usecase, mutating the stable result is a totally fine thing to do.

In my opinion this PR would break a lot of things and should not be merged.

[github-actions]

Size Report

Bundles

File	Size	Gzip	Brotli
runtime-dom.global.prod.js	87.1 kB	33.1 kB	29.9 kB
vue.global.prod.js	133 kB	50 kB	44.8 kB

Usages

Name	Size	Gzip	Brotli
createApp	48.4 kB	19 kB	17.4 kB
createSSRApp	51.6 kB	20.3 kB	18.5 kB
defineCustomElement	50.7 kB	19.8 kB	18.1 kB
overall	61.7 kB	23.9 kB	21.7 kB

[codspeed-hq]

CodSpeed Performance Report

Merging #8464 will not alter performance

_{Comparing Alfred-Skyblue:type-ref (bb2adc5) with main (9fa8241)}

Summary

✅ 53 untouched benchmarks