-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
React higher-order components run into trouble with assignability of Readonly
intersections
#27484
Comments
intersections on both the source and the target. Fixes microsoft#27484.
Minimal repro: function f<P>(
a: { weak?: string } & Readonly<P> & { name: "ok" },
b: Readonly<P & { name: string }>,
c: Readonly<P> & { name: string }) {
c = a; // Works
b = a; // Effectively identical, doesn't work
} |
Right. In essence, the current assignability rules only relate I'm starting to think a better solution to the original problem is to change the I edited the issue title to make clear that I'm looking for a solution to the original scenario of React higher-order components, which may or may not take the form of extending the assignability rules to handle |
Readonly
interfering with assignability of intersections (affects React higher-order components)Readonly
intersections
I'm trying to answer this Stack Overflow question on typing a React higher-order component. I've been recommending intersections rather than
Exclude
for expressing the inner and outer prop types for a higher-order component since TypeScript's type relations and inference seem to handle intersections better thanExclude
in general. (I know this practice has problems; if you know a better way, please let me know! For now,Object.assign
and JSX spreads still generate intersections.) However, React also usesReadonly
for prop types, and I've hit an ugly case in whichReadonly
is getting in the way of matching up the intersections between the supplied and expected props. Many simpler cases seem to work OK, but this one fails.I'm not sure if this is a bug but would like the TypeScript team's feedback on the scenario, since the question has been up on Stack Overflow and I doubt anyone from the TypeScript team will ever look at it there. Hopefully, in consideration of my answering hundreds of TypeScript questions on Stack Overflow and helping triage tens of other issues here, I can have the privilege of occasionally escalating questions I can't answer to the TypeScript team. Thanks!
TypeScript Version: master (8feddcd)
Search Terms: readonly mapped type intersection assignable assignability higher order components
Code
Note: if we replace
React.ComponentClass
withReact.ComponentType
, then the issue does not reproduce due to #27385. This may be why it hasn't been noticed so far.Expected behavior: No error.
Actual behavior: Error as marked.
Playground Link: Link for non-React example
Related Issues: Possibly #27201
The text was updated successfully, but these errors were encountered: