typescript - Vue's ref doesn't maintain types of nested private properties - Stack Overflow

admin管理员组

文章数量:1122832

This problem occurs both with arrays and objects. Using shallowRef instead of ref solves it but I often need deep reactivity. Now I use casting, but I'm not happy with it. What's the best way to address this problem?

class Bar {
    private val = 1;
}

class Foo {
    private bar = new Bar();
}

const fooRef = ref(new Foo());

const foo: Foo = fooRef.value; // Property bar is missing in type {} but required in type Foo
const bar = fooRef.value.bar; // Property bar does not exist on type {}

const baz = ref([new Foo()]); 
const z = baz.value[0].bar.val; // Property bar does not exist on type {}

Packages I use:

"typescript": "^5.6.3",
"vue": "^3.5.12",

This problem occurs both with arrays and objects. Using shallowRef instead of ref solves it but I often need deep reactivity. Now I use casting, but I'm not happy with it. What's the best way to address this problem?

class Bar {
    private val = 1;
}

class Foo {
    private bar = new Bar();
}

const fooRef = ref(new Foo());

const foo: Foo = fooRef.value; // Property bar is missing in type {} but required in type Foo
const bar = fooRef.value.bar; // Property bar does not exist on type {}

const baz = ref([new Foo()]); 
const z = baz.value[0].bar.val; // Property bar does not exist on type {}

Packages I use:

"typescript": "^5.6.3",
"vue": "^3.5.12",

• typescript
• vue.js
• vuejs3
• vue-typescript

Share Improve this question Follow asked Nov 21, 2024 at 14:28 Eugene BarskyEugene Barsky 5,99233 gold badges2020 silver badges4141 bronze badges 10

• bar is private, it's not expected to be accessed. Vue reactivity is unfriendly to classes, I'd advise against using them together in general, there's rarely a real necessity to do this. The best way would be to use plain objects, this is the case reactivity api was primarily made for – Estus Flask Commented Nov 21, 2024 at 14:34
• @EstusFlask I cannot change the majority of files used in the project. – Eugene Barsky Commented Nov 21, 2024 at 14:36
• Then consider explaining your case in details, so an answer that addresses it could be given. There's no problem in general because you wouldn't care about the existence of "bar", it's private – Estus Flask Commented Nov 21, 2024 at 14:39
• The problem is that I get errors in my IDE because of type mismatch, as in the first assignment, which doesn't even mention bar – Eugene Barsky Commented Nov 21, 2024 at 14:40
• Generally speaking it breaks the whole idea of type safety. – Eugene Barsky Commented Nov 21, 2024 at 14:41

 |  Show 5 more comments

2 Answers 2

Sorted by: Reset to default 1

ref creates deeply reactive object that does ref unwrapping, and ref type works by extracting public members, this is a way for it to implement unwrapping. This is important for class types because their compatibility requires their private members to match.

So it's expected that fooRef.value type may not be Foo, at least when the class implementation uses reactivity API. This requires to use type assertion when a developer is certain that the type is correct.

This can be done at the time where a value is consumed:

const foo = fooRef.value as Foo;

Or when a ref is created:

const fooRef = ref(new Foo()) as Ref<Foo>;

Which is not the same as ref<Foo>(new Foo()), the latter works the same way as ref(new Foo()).

You could remove private (maybe also protected props) and thus using only the public interface:

Playground

type Public<T extends object> = {[K in keyof T]: T[K]} extends infer A ? A : never;
let foo: Public<Foo>;

foo = fooRef.value;

本文标签： typescriptVue39s ref doesn39t maintain types of nested private propertiesStack Overflow