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

v11 types: new shouldForwardProp type is overly restrictive #1641

Closed
grncdr opened this issue Nov 18, 2019 · 5 comments
Closed

v11 types: new shouldForwardProp type is overly restrictive #1641

grncdr opened this issue Nov 18, 2019 · 5 comments
Labels

Comments

@grncdr
Copy link

grncdr commented Nov 18, 2019

Current behavior:

I have been trying out the new @next tags, and have run into a type error with code that previous type-checked and worked. I'm fairly certain this is due to the changes in #1624

The shouldForwardProp option is now inferred to being of type (prop: keyof Props) => prop is ForwardedProps. But this restricts prop to being one of the known props of an element type.

To reproduce:

See the code sandbox for an example that used to work and now fails

Expected behavior:

I think that the argument to shouldForwardProp should always just be a string, since at the moment styled is called, we don't know what additional props the component might accept.

Environment information:

  • Typescript 3.6.2
  • Emotion libs @next (see codepen for exact versions)
  • @types/react 16.9.4
@grncdr
Copy link
Author

grncdr commented Nov 18, 2019

cc @JakeGinnivan

I don't think this issue is very severe: one can explicitly annotate the shouldForwardProp callback to work around it:

styled('div', {
  shouldForwardProp: (prop: string) => ...
})(...)

@JakeGinnivan
Copy link
Contributor

Ah I see, the prop is added to the types after the create styled. Good point.

Thoughts on if it should allow string or PropertyKey. I guess that comes down to if my type had symbol/number based keys, would isValidProp be able to handle it.

@Andarist
Copy link
Member

string is IMHO fine, both numbers and symbol are technically allowed, but I havent ever seen them used as props keys

@JakeGinnivan
Copy link
Contributor

Giving it a go, PropertyKey is actually simpler from a types point of view. Otherwise I need to use Extract<keyof Props, string> instead of keyof Props

@Andarist
Copy link
Member

We believe this got fixed by #1643, once we release a new version please take a look to check out it this resolved your issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants