Skip to content

TSX type inference is broken when using intersection types #21632

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
iyegoroff opened this issue Feb 5, 2018 · 7 comments
Closed

TSX type inference is broken when using intersection types #21632

iyegoroff opened this issue Feb 5, 2018 · 7 comments
Assignees
Labels
Needs Investigation This issue needs a team member to investigate its status.

Comments

@iyegoroff
Copy link

iyegoroff commented Feb 5, 2018

TypeScript Version: 2.7.1, 2.8.0-dev.20180204

Search Terms: jsx tsx intersection

Code

import * as React from 'react';

type Props<T> = T & {prop: string};

class Component<T = {valid: string}> extends React.Component<Props<T>> {}

<>
  <Component prop={''} invalid={''} />
  <Component prop={''} valid={''} invalid={''}/>
</>

Expected behavior:
Should generate 2 errors as in 2.6.2:

main.tsx(8,14): error TS2322: Type '{ prop: ""; invalid: ""; }' is not assignable to type 'IntrinsicAttributes & IntrinsicClassAttributes<Component<{ valid: string; }>> & Readonly<{ childr...'.
  Type '{ prop: ""; invalid: ""; }' is not assignable to type 'Readonly<Props<{ valid: string; }>>'.
    Property 'valid' is missing in type '{ prop: ""; invalid: ""; }'.
main.tsx(9,35): error TS2339: Property 'invalid' does not exist on type 'IntrinsicAttributes & IntrinsicClassAttributes<Component<{ valid: string; }>> & Readonly<{ childr...'.

Actual behavior:
No errors are generated

Playground Link: -

Related Issues: maybe related #21427

@RyanCavanaugh RyanCavanaugh added the Needs Investigation This issue needs a team member to investigate its status. label Feb 5, 2018
@RyanCavanaugh
Copy link
Member

@weswigham thoughts on this?

@weswigham
Copy link
Member

I think the jsx inference/contextual typing PR I currently have open is mostly to fix exactly this, since I discovered the same issue when looking at changing formik.

@weswigham
Copy link
Member

weswigham commented Feb 5, 2018

Also, hold on: those 2.6.2 errors are themselves erroneous. Setting a default doesn't constrain the type variable - literally any props should be be OK to pass for that component - we just messed up before and instantiated with the default like it was the constraint before.

@RyanCavanaugh
Copy link
Member

Setting a default doesn't constraint the type variable - literally any props should be be OK to pass for that component

This was my interpretation as well. Seems useless to have a generic component if you're not allowed to infer a type from its props.

@iyegoroff
Copy link
Author

@weswigham, so the actual behavior in 2.7.1 is correct and it will stay like this after your PR will be merged?

@weswigham
Copy link
Member

Yeah. You should be using extends in that type definition if you actually wanted that field required.

@iyegoroff
Copy link
Author

OK, thanks for clarification.

@microsoft microsoft locked and limited conversation to collaborators Jul 3, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Needs Investigation This issue needs a team member to investigate its status.
Projects
None yet
Development

No branches or pull requests

3 participants