Add Typescript definitions.

[DaanDeMeyer]

Having Typescript definitions in the repository itself saves users from having to download the definitions separately and changes to the main redux definitions can be more easily applied to the react-redux definitions.

I've taken the definitions from the DefinitelyTyped repository. The only change I made is the addition of the generic State type to the connect function so the State parameter of the mapStateToProps function can actually be typed instead of being of the 'any' type.

The rest of the definitions seem to be correct.

[timdorr]

Any chance we can get testing for these, like we do on Redux? https://github.com/reactjs/redux/blob/master/test/typescript.spec.js

[Guria]

This typings provided doesn't fit to be bundled with package because the are global. You must convert it to be external module definitions (using import, export keywords, not using global namespace imports, etc)

[bbenezech]

this.props.dispatch is missing in connect() and connect(mapStateToProps) forms.

[DaanDeMeyer]

@timdorr Do the Typescript definitions have to take into account that the library can be used as an UMD module? Also, can I make use of the Typescript 2.0 features for the definitions?

@bbenezech I don't see what's missing. Could you explain more in depth?

[bbenezech]

@DaanDeMeyer Sorry, disregard.
I overlooked connect<TOwnProps, TStateProps, TDispatchProps>.
I can use TDispatchProps and inform my component that it has a dispatch prop passed from its HOC.

Really sorry. Still trying to wrap my head with TS

[DaanDeMeyer]

Since I'm not using react-redux anymore I'm not going to be able to implement testing or maintain definitions for the project so I'm closing the pull request.

[Zalastax]

@codeandcats suggested I fork and re-request these additions. Before I start, I wonder what are the tasks that need to be performed? I don't mind opening a PR but I'd rather not just copy the code without adding anything myself, unless we are content with the state of this PR before it was closed.
@DaanDeMeyer raised some questions which I'd like to get answered before I begin.

• @timdorr Do the Typescript definitions have to take into account that the library can be used as an UMD module? Also, can I make use of the Typescript 2.0 features for the definitions?
• The rest of the definitions seem to be correct. Anything missing? Probably needs to be converted to external module though.
• Do we have any typescript files that can be used to test this with typescript-definition-tester?

[codeandcats]

@timdorr _bump_

Also, imho it would be fine to target TypeScript 2 since it's backwards compatible with 1.x code so there's really no reason consumers shouldn't be using it now.

[timdorr]

Since MS is pushing the whole @types namespacing on npm, I don't think we need to add them here. They exist on DT and that should be good enough.

[bbenezech]

@timdorr
Redux typings and flow typings are successfully maintained in-house, why not react-redux?
DT is a gigantic mess, noise there is overwhelming. It makes sense to have it maintained here, with PR merged by react-redux maintainers, unless you do want to reduce the load on the library's maintenance, which is very understandable.

[timdorr]

It's more that our current set of maintainers don't use TS, so we don't have any ability to maintain those typings. If you want to see it here, I'm more than happy to accept a PR, but understand that we'll rely on the community to guide those typings. That's how we did the TS and Flow typings on Redux.

I can basically just read through comments and mash the appropriate button. I'm a typing dunce 😄

[Guria]

Since MS is pushing the whole @types namespacing on npm, I don't think we need to add them here

It is not true. @types repos is a fallback for libs that doesn't maintain typings in house. It also introduces compatibility issues.
In house typings still prefered way, because lives near source code and shares the same version.
Of course there is a cost for it too:

• increased maintainance load
• it affects semver: breaking change in typings would require major bump in whole package

But again it is much more convinient for consumer to use lib with typings included:

• no additional deps to install and maintain
• typings always describe code that you use since it located at the same package
• it usually have higher quality than 3rd parties

[jimbolla]

I think the optimal situation is to have Flow/TS typings collocated with the code, but have at least 1 project maintainer committed to keeping them updated in step with code changes.

[bbenezech]

Ok, let's try. Go easy on me #538