TS: issues with private class properties with ref vs shallowRef for typed arrays

[ludwig801]

Vue version

3.5.11

Link to minimal reproduction

https://play.vuejs.org/#eNqNU99r2zAQ/leEnlJIHcrYS+YGutCHDbaVrm9RGKpzTtTJktDJWULw/76THP9YYWnBYPu+T3ff3X068Tvnsn0NfM7zAJXTMsBCGMbyJ8Cw3Cm9YfO91DXcCo47qbX9c+e9PArOZv8lbgDcmJXPRrnpFwuvXGAIoXZMS7OlMwEFJ1RVzvrAhqSltxUTPJul36hV8E8978S+HZdaIrJmxIwBYrHZjOXX122yGMuoyHDSQzll554eoRwydDWEKaxB0jnqm92OjuTn4qv1YrJaX/UFZWLakoWjg07has0mKCtogxJZ2EHUkC+uukL93KhKRF6lj4NsR7fgUxoYHSrVNntBa2h/p7gNwQtbOaXB/3BBUVLB5ywhEUu6v6ZYKTXCtAOKHRS/WyD4eoi/4CHGBH/wgOD3NJceC9JvIbTw/c/vcKDvHqzsptbEvgA+AlpdR5Et7XNtNqR7xEtyv6R1KbN9wvtDAINdV1FoZDaJn7a2vND7IPdD9jGdE6ahMXbGoAnCITmjSH7qfHUSPrKdV3vyb/d+8NbNGQZPwvq1GxtUQfvdycAUPdixzynqZ62K8+ufBBFPWjqLx+v49iW5aP5o3w2UyiStmKdBpAs6HxzZS6fWoQj4Tuc+Ay2GXNssJq9d+WsPPq6IOqA5Zzc3vPkLvgN7ng==

Steps to reproduce

Essentially the same issue as reported here: vuejs/language-tools#4970 and was marked as upstream.

What is expected?

When using ref, if the given type is an array type of instances of a class with private properties, its type remains the same across it's usages.

What is actually happening?

When using ref with an array type, the iterable class type is unwrapped and it's private properties are lost, generating errors when that class type is expected, since they now do not match.

System Info

No response

Any additional comments?

No response

[jh-leong]

Closing as a duplicate of #2981. As a workaround, see: #2981 (comment)

[ludwig801]

Closing as a duplicate of #2981. As a workaround, see: #2981 (comment)

I do not believe this is a duplicate, for the following reason: using ref<Class> works as intended, and Class is not unwrapped. Using ref<Class[]> does unwrap Class. In the mentioned duplicate, they mention TS limitations for this, but these seem to have been overcome (since single instance typing does not trigger any error), and seems to remain only for typed arrays.

[jh-leong]

From what I understand, the limitation on unwrapping private fields is still present: Playground

[ludwig801]

From what I understand, the limitation on unwrapping private fields is still present: Playground

That might be so, but my question remains: why is unwrapping done when using array syntax and not when using single instance syntax? I.e.: why does ref<MyClass> map to type Ref<MyClass>, whilst ref<MyClass[]> maps to type Ref<{ ...unwrapped_MyClass }[]> instead of Ref<MyClass[]>?

The unwrapping seems to be the hardest, and not the easiest solution. If no unwrapping was done, I can't see how there would be any issue...

[jh-leong]

I.e.: why does ref<MyClass> map to type Ref<MyClass>

I’m not entirely sure I understand your question. Both cases involve unwrapping, as shown in the Playground example above:

class Foo {
  private foo = 1
}

const t1 = ref<Foo[]>([new Foo])
//     ^ Ref<{}[]>
const t2 = ref<Foo>(new Foo)
//     ^ Ref<{}>, not Ref<Foo>

The reason for unwrapping and the available workaround are explained in more detail in #2981. You might find it helpful to check that out.

[ludwig801]

I.e.: why does ref<MyClass> map to type Ref<MyClass>

I’m not entirely sure I understand your question. Both cases involve unwrapping, as shown in the Playground example above:

class Foo {
  private foo = 1
}

const t1 = ref<Foo[]>([new Foo])
//     ^ Ref<{}[]>
const t2 = ref<Foo>(new Foo)
//     ^ Ref<{}>, not Ref<Foo>

The reason for unwrapping and the available workaround are explained in more detail in #2981. You might find it helpful to check that out.

From what I understand, unwrapping is used to provide the <template> section with "raw" types from the setup/definition section such that, for example, Ref<number> becomes number. I understand how this is done for the sake of being able to use the unwrapped syntax in the SFC's <template>.

What I don't understand is why unwrapping does not stop when it reaches a well-defined class type. I mean, in such cases, typing is definitive an clear, and no further unwrapping is required. Ref<MyClass> or Ref<MyClass[]> will never become anything else.

When initializing through the use of the ref( object ) method, I understand why it must attempt to deeply analyze the given object, when that object is of an arbitrary type, which can only be understood by analyzing it. However, when that object is from a well defined type or class, I don't understand the need to try and "destructure" said object into its constituents.

The type is already there. You're only trying to create a new unecessary (and sometimes wrong, as is the case) type.