ref returned by toRefs(props) have type Ref<X | undefined> | undefined

[Waujito]

Vue version

latest, 3.2.37

Link to minimal reproduction

https://codesandbox.io/s/vigorous-sound-6m9x2d

Steps to reproduce

Check sandbox link provided in minimal reproduction field and run npm run type-check in terminal:

What is expected?

Expected that the type-check action returns no error in buggedComponent.vue that is
the type of optionalProperty in anyProperty assignation detects as string because all conditions that may detect and prevent undefined type are passed:

What is actually happening?

typescript compiler detects type of the optionalProperty in anyProperty assign condition as string|undefined

System Info

No response

Any additional comments?

If you dont want to check the reproduction link, there are some photos that describes the problem:

[LinusBorg]

toRef() works as expected. The prop is possibly undefined, so the generated ref possibly contains and undefined value: Ref<string | undefined>. The propblem is only with toRefs()

For toRefs(), this is a bit trickier and I'd need our TS experts like @pikax to chime in. it seems that the types of toRefs() return Ref<Type | undefined> | undefined for a possibly undefined props, which is not accurate in this scenario - the prop object will always have this key (its value just may be undefined), so we know we will always have get a Ref<string | udnefined>.

However, I think the core issue is TS rather recent differentiation between an optional property and a property whose value is undefined. The following change to the reproduction's code generates the expected type for the ref:

const props = defineProps<{
  requiredProperty: string;
  optionalProperty: string | undefined;
}>();

...and it's better reflecting reality as well: the prop can't be missing on that props object, it can only be undefined. However, this is not a proper workaround for now either, as that so-defined prop can no longer be left out when being used in a parent:

And from this perspective, the prop should really be optional, not just its valzue possibly undefined - we want to be able to completely omit it in the parent - but the property key should exist internally on the propsobject for consistency.

Tricky 🤔

[pikax]

For toRefs(), this is a bit trickier and I'd need our TS experts like @pikax to chime in. it seems that the types of toRefs() return Ref<Type | undefined> | undefined for a possibly undefined props, which is not accurate in this scenario - the prop object will always have this key (its value just may be undefined), so we know we will always have get a Ref<string | udnefined>.

This is only valid for props, but toRefs is used in on the user land, I believe the current toRefs definition is accurate for the type coming from defineProps.

I think we can update the return type from props to remove the optional property, props can be converted to options when we create the PublicComponent type (aka $props).

[Waujito]

toRef() works as expected. The prop is possibly undefined, so the generated ref possibly contains and undefined value: Ref<string | undefined>. The propblem is only with toRefs()

I agree. But, I think, the main topic of this issue is that it is impossible to separate Ref<string> from Ref<undefined>

[LinusBorg]

But, I think, the main topic of this issue is that it is impossible to separate Ref from Ref

If you have an optional prop (= it can be undefined), then a ref created from that optional prop will possibly contain undefined. That's not a bug, and Vue can't solve that for you - you need to do that.

if you have a piece of code that expects Ref<string>, then check the ref's value before calling that code. How do do that exactly is depending on your code (for details please don't use this issue, ask the community on discord or in this repo's discussions tab). Pseudocode:

const myProp: Ref<string | undefined> = toRef(props, 'myProp')

function myFn (myProp: Ref<string>) { ... }

if (myProp.value) {
  myFn(myProp)
}

you would need to do the exact same thing for a possibly undefined plain variable (const myVar: string | undefined)

[LinusBorg]

This is only valid for props, but toRefs is used in on the user land, I believe the current toRefs definition is accurate for the type coming from defineProps.

True, forgot to mention it, but was aware

I think we can update the return type from props to remove the optional property, props can be converted to options when we create the PublicComponent type (aka $props).

Great, agreed.

[Waujito]

But, I think, the main topic of this issue is that it is impossible to separate Ref from Ref

If you have an optional prop (= it can be undefined), then a ref created from that optional prop will possibly contain undefined. That's not a bug, and Vue can't solve that for you - you need to do that.

if you have a piece of code that expects Ref<string>, then check the ref's value before calling that code. How do do that exactly is depending on your code (for details please don't use this issue, ask the community on discord or in this repo's discussions tab). Pseudocode:

const myProp: Ref<string | undefined> = toRef(props, 'myProp')

function myFn (myProp: Ref<string>) { ... }

if (myProp.value) {
  myFn(myProp)
}

you would need to do the exact same thing for a possibly undefined plain variable (const myVar: string | undefined)

Did you check the reproduction?

if(myProp.value){myFn(myProp)}  // won't work

[pikax]

Did you check the reproduction?

Your reproduction code is invalid, you are assigning ref<string> to a string.

The only valid point is the Ref<string | undefined> | undefined which is a bug.

[Waujito]

Did you check the reproduction?

Your reproduction code is invalid, you are assigning ref<string> to a string.

The only valid point is the Ref<string | undefined> | undefined which is a bug.

Oh, yes, sorry.
But i fixed it and anyways this returns an error:

[pikax]

#6421 will fix that error.

[Waujito]

Ok thank you

[LinusBorg]

@pikax you sure? I think what OP tries to do here would require casting or a new ref.

They are checking for .value to not be nullish, but that will not make the existing Ref<string | undefined> ref into Ref<string>, as it could be set to undefined later again. Object ins TS can never change their original type.

They would need to return a fresh ref, that might work, but not the same one. This works (for both variations of the demonstrated problem:

const anyProperty: Ref<string> =
  props.optionalProperty && optionalProperty && optionalProperty.value
    ? ref(optionalProperty.value)
    : ref("qwerty");

[pikax]

@LinusBorg I believe that's typescript type narrowing, it makes sense if you think about, because the ref can be undefined, even if you check if .value is undefined nothing prevents to be changed afterwards:

declare const r : Ref<string | undefined>

const refString = r.value  ? r : ref(''); // the type you are hoping to get here is `Ref<string>` if I understand you

r === refString; // true if `r.value` is truthy.


r.value = undefined; // this is type safe because `r` allows undefined

refString.value === undefined; // because they share the same instance

As you can see from the example you must use another instance since the original ref is Ref<string|undefined>