Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ref unwrapping causes generic type inference to fail #1930

Open
stefnotch opened this issue Aug 21, 2020 · 1 comment · May be fixed by #9516
Open

Ref unwrapping causes generic type inference to fail #1930

stefnotch opened this issue Aug 21, 2020 · 1 comment · May be fixed by #9516
Labels
🍰 p2-nice-to-have Priority 2: this is not breaking anything but nice to have it addressed. scope: types ✨ feature request New feature or request

Comments

@stefnotch
Copy link

stefnotch commented Aug 21, 2020

Version

3.0.0-rc.7

Reproduction link

https://codesandbox.io/s/stupefied-beaver-500yq?file=/src/test.ts:0-404

Steps to reproduce

Write the following, reasonably minimal code.

import { reactive, ComputedRef } from "vue";

interface Foo {
  position: number;
}

interface Bar {
  position: number;
  callback: (data: any) => void;
}

function createStuff(name: string, position: ComputedRef<number>) {
  const a: Foo = reactive({
    position: position,
  });

  const b: Bar = reactive({
    position: position, // Issue happens here
    callback: (v) => {},
  });
}

What is expected?

That the types are inferred correctly.

What is actually happening?

In the Bar case, Typescript complains about Type 'ComputedRef<number>' is not assignable to type 'number'. In the Foo case, everything works as expected.


This might as well be a bug with Typescript, but considering that it affects Vue's reactive API due to the automatic ref unwrapping, I thought I'd open it here first.

@pikax
Copy link
Member

pikax commented Aug 22, 2020

Not sure if this is a bug, the cause seems to be typescript cannot infer v type correctly, which can be fixed by:

  const b: Bar = reactive({
    position: position,
    callback: (v:any) => {}
  });

We can add an overload to provide a better error message, this is the error with the overload:
image

That error comes because of the noImplicitAny flag on compilerOptions, if you set it to false you won't get the error.

@sodatea sodatea added the 🍰 p2-nice-to-have Priority 2: this is not breaking anything but nice to have it addressed. label Mar 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🍰 p2-nice-to-have Priority 2: this is not breaking anything but nice to have it addressed. scope: types ✨ feature request New feature or request
Projects
None yet
4 participants