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

Suggestion: Difference Types #15059

Closed
mattinsler opened this issue Apr 6, 2017 · 4 comments
Closed

Suggestion: Difference Types #15059

mattinsler opened this issue Apr 6, 2017 · 4 comments
Labels
Duplicate An existing issue was already created

Comments

@mattinsler
Copy link

The Problem

Let's say that we're building a redux-style connect method. In order to have well-enforced typing on the resulting component it would be useful to have the idea of a difference type.

interface Props {
  foo: number;
  bar: string;
}

class FooComponent extends React.Component<Props, void> {
  public render() { /* ... */ }
}

function mapStateToProps(state) {
  return { foo: state.something.value };
}

const Foo = connect(mapStateToProps)(FooComponent);

// Then, the following should pass type-checking
<Foo bar="baz" />

The way we could type the connect method would be as follows (sorry, it's long):

type ConnectMethod = <TState, TProps extends TStateProps, TStateProps>(mapStateToProps: (state: TState) => TStateProps) => (component: React.ComponentClass<TProps>) => React.ComponentClass<TProps - TStateProps>;

Proposed Solution

The proposal is to add difference types. This would be where the keys of one interface could be subtracted from the keys of another interface.

The theoretical syntax would be to use a - to specify this.

interface Foo { foo: number; bar: string; }
interface Bar { bar: string; }
type Baz = Foo - Bar; // equivalent to { foo: number; }
@aluanhaddad
Copy link
Contributor

Duplicate of #4183

@AJamesPhillips
Copy link

AJamesPhillips commented Apr 7, 2017

This is almost exactly my use case here as well: #14626 Good to see others wanting this too. Not sure how challenging it would be to implement.

@merrywhether
Copy link

merrywhether commented May 9, 2017

Yeah, this comes up a lot in the React ecosystem a lot due to the proliferation of HOCs in general (I hit it in react-router). I've upvoted all the relevant issues, including #12215 which seems to be most likely to happen.

For instance, in https://github.com/DefinitelyTyped/DefinitelyTyped/blob/fe1b612ef0d9ffd45114431adac61b5e6ee1173f/types/react-router/index.d.ts#L101, the return should be React.ComponentClass<P - RouteComponentProps<any>> and then you wouldn't need to have explicit type annotation in the withRouter signature (and then the function parameters shouldn't need RouteComponentProps<any> unioned with their own types).

@RyanCavanaugh RyanCavanaugh added the Duplicate An existing issue was already created label May 9, 2017
@mattinsler
Copy link
Author

Great to see this is consolidating and moving along!

awesson added a commit to awesson/hieroglyph that referenced this issue May 14, 2017
The C# app now runs npm to run the start.js script which starts the
webserver.

Also started some work on recieving the initial state and saving that
state off.

Updated some modules which caused a typing issue in connect(). Had to
move some interface definitions around to get it working. Ideally it
would be fixed with microsoft/TypeScript#15059
@microsoft microsoft locked and limited conversation to collaborators Jun 21, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Duplicate An existing issue was already created
Projects
None yet
Development

No branches or pull requests

5 participants