Mapped type for combineReducers in index.d.ts

[mkusher]

Since typescript 2.1 there is a cool feature microsoft/TypeScript#12114 which can improve type inference for combineReducers. No need to explicitly pass state type to combineReducers any more.

Note: it requires typescript 2.1

[kevinthiart]

This doesn't only allow for more convenient type inference: Assuming your Reducers are defined properly, this will also enforce, at compile time, most (or all?) of the validation done in combineReducers, such as "No reducer provided for key", "Reducer returned undefined during initialization", "Reducer returned undefined when probed with a random type", etc.

It will also solve an issue where Reducer<any> can be satisfied with something like:

(state?: SomeState, action: Action) => NotSomeState;

In other words, a function that returns NotSomeState instead of SomeState. For this reason alone I'd love for all instances of Reducer<any> to be removed from the Redux typedefs.

This does make the typedef much more strict though. It is a breaking change for people who ignored the above warnings, or people who use the import * as reducers from './reducers' trick, which could create an object with unexpected properties, some of which aren't reducers.

[mkusher]

@kevinthiart you're right, but ts 2.1 is also a breaking change so. Btw, I don't see any other places where Reducer<any> type is used

[aikoven]

Since this is a breaking change, shouldn't this be rebased onto the next branch? Not really sure though because next is very outdated. See #2165. Also #1342

Let's also update Reducer type to enable strict null checking:

export type Reducer<S> = <A extends Action>(state: S | undefined, action: A) => S;

[mkusher]

@aikoven I've added strict null check to spec & undefined to reducer. Not sure what needs to be done with the next branch, should I resend PR with target branch next? As I see there is a difference between index.d.ts in master and in next branch. So should I include only my changes or whole index.d.ts?

[aikoven]

cc. @timdorr

[timdorr]

@mkusher I'm not sure of how this would be handled according to semver, but I think it would be a bad idea to break typing compatibility on a patch or minor version bump. The conservative approach would be to wait until the next major, which is what the next branch is for.

I would see about getting these typings published under the @types npm namespace too. Those can be versioned independently of the library, to correspond better with TS features.

[mkusher]

Closing this PR in favor of #2182