Return types of state variables with nested ref/computed properties don't match the specified type #2696
-
ReproductionSteps to reproduce the bugThis issue might be related to #2658, but the linked PR does not solve it. If a state variable contains a prop that is itself a ref or a computed value, the return type of that variable will 'simplify' that away (i.e. a prop with type ComputedRef will become just number). That means, however, that using the return type of this state variable as a parameter in a function will throw a ts error. A workaround is to expose the state variable through a getter in the store, but I kinda hate that because it breaks consistency. And since the state variable has to be exported to keep reactivity, there is no way of knowing if I can access it directly or have to use the getter without looking into the store, where it may or may not be documented. type Item = {
name: string
price: ComputedRef<number>
}
type Listing = {
id: string
category: string
items: Item[]
}
export const useStore = defineStore('counter', () => {
const listings: Ref<Listing[]> = ref([])
function someFnAcceptingAListing(listing: Listing) {
console.log(listing)
}
function getListings() {
return listings
}
return { listings, someFnAcceptingAListing, getListings }
})
const store = useStore()
// Access listings in different ways.
const exportedListings = store.listings // ❌ not type Listing[]
const { listings: storeToRefsListings } = storeToRefs(store) // ❌ not type Ref<Listing[]>
const getterListings = store.getListings() // ✅ Ref<Listing[]> !
// Try to pass listings to a function that should accept them as parameter.
// All of these work fine in runtime, but some the first 2 throw a ts error.
store.someFnAcceptingAListing(exportedListings[0]) // ❌ error
store.someFnAcceptingAListing(storeToRefsListings.value[0]) // ❌ error
store.someFnAcceptingAListing(getterListings.value[0]) // ✅ ok!Expected behaviorAll 3 methods of accessing the state variable should result in the same return type. Actual behaviorI suppose returning the state variable directly triggers some internal unwrapping, which breaks the type? Anyways, returning such a complex typed variable changes the original type. Additional informationNo response |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 2 replies
-
|
The problem comes the casting on the ref being wrong. refs auto unwrap nested refs (and computed, etc). Once the ref is properly typed, type errors go away Note that putting a computed/ref within the nested data can create issues during SSR because it allows the data source to be duplicated during serialization. |
Beta Was this translation helpful? Give feedback.
-
|
I see, thanks for the reply! I wasn't aware of the UnwrapNestedRefs type. Do you happen to know if there is a recommended best practice on how to handle nested computeds? |
Beta Was this translation helpful? Give feedback.
-
|
There isn't a recommended way because it really depends on what you want to do. Sharing refs is allowed but it does mean that you will need to use |
Beta Was this translation helpful? Give feedback.
The problem comes the casting on the ref being wrong. refs auto unwrap nested refs (and computed, etc). Once the ref is properly typed, type errors go away
Note that putting a computed/ref within the nested data can create issues during SSR because it allows the data source to be duplicated during serialization.