Skip to content

Prop with validator breaks prop types for component #2474

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

Closed
KaelWD opened this issue Oct 23, 2020 · 6 comments
Closed

Prop with validator breaks prop types for component #2474

KaelWD opened this issue Oct 23, 2020 · 6 comments
Labels
has workaround A workaround has been found to avoid the problem scope: types

Comments

@KaelWD
Copy link
Contributor

KaelWD commented Oct 23, 2020

Version

3.0.2

Reproduction link

https://codesandbox.io/s/blissful-darwin-mi9ul

Steps to reproduce

Try to access props.type

What is expected?

No error

What is actually happening?

Property 'type' does not exist on type 'Readonly<...


Removing the validator or using as Prop<string> fixes the error, but it should be inferred without breaking the component.

@HcySunYang
Copy link
Member

Use arrow function instead, or explicitly add an annotation to this: validator(this: void, val: string){ ... }

@posva posva added scope: types has workaround A workaround has been found to avoid the problem labels Oct 26, 2020
@KaelWD
Copy link
Contributor Author

KaelWD commented Oct 26, 2020

Ah yeah it's vuejs/vue#8679 again, thanks.

@JensDll
Copy link
Contributor

JensDll commented Nov 21, 2020

I would like to add that this is a design limitation in TypeScript; see this issue microsoft/TypeScript#38845. And I believe that the example under Annotating Props in the docs will have this problem as well.

@yyx990803
Copy link
Member

/cc @vuejs/docs

@LinusBorg
Copy link
Member

Documentation as been amended with proper instructions, we can close this here.

@kuanyui
Copy link

kuanyui commented Mar 10, 2021

Still encountered the same issue even if following doc... (vue 3.0.7, typescript 4.2.3)
#2738 (comment)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
has workaround A workaround has been found to avoid the problem scope: types
Projects
None yet
Development

No branches or pull requests

7 participants