Add TypeScript definitions #1413

ulfryk · 2016-02-16T16:05:22Z

It would be great if try to not use too much any - it's just like working without support of typscript… :(

Consider more strict approach like:

interface Action { type: any; } interface Reducer<S> extends Function { <S>(state: S, action: Action): S; } interface ReducersMapObject<S> { [key: string]: Reducer<S> } interface Dispatch extends Function { <A extends Action>(action: A): A; }

Or even better

interface Action<T> { type: T; } interface Reducer<S, T> extends Function { <S>(state: S, action: Action<T>): S; } … interface Dispatch<T> extends Function { <A extends Action<T>>(action: A): A; }

so anyone can implement his own strict actions:

enum ActionType {A, B, C} interface MyAction implements Redux.Action<ActionType> { type: ActionType; payload: MyPayloadType;

or dynamic ones:

interface MyAction implements Redux.Action<any> {}

Why isn't this sufficient?

interface Action { type: string; }

If you want to have strict actions you can just do:

enum ActionType {A, B, C} interface MyAction<P> { type: ActionType; payload: P; }

And it will be assignable to Action.

Also, reducer should not be constrained to accept only some selected actions. It should accept any possible action and bypass ones it doesn't need to handle.

aikoven · 2016-02-17T05:50:26Z

We can't avoid any here. Middleware potentially allows dispatch to accept anything: functions (thunks), promises, etc. Its return type could also be anything.

We can. Just make it generic:

interface Dispatch extends Function { <A>(action: A): A; }

or if dispatch returns output changed by middleware:

interface Dispatch extends Function { <A, O>(action: A): O; }

This is one of typings that is necessary for strict typing of any redux based app. If dispatch can return anything and can't be parametrised then static typing is of no value here…

How do we use it? Considering first option we'd have:

export interface Store<S> { dispatch: Dispatch<any>; // ... }

So the only place where type parameters would be useful is the app code, e.g.

@connect( state => /* ... */, (dispatch: Dispatch<Action>) => { return { someActionCreator: () => dispatch(someActionCreator) } } )

But nothing prevents you to set up custom Dispatch type with constraints that fit you needs:

type MyDispatch = (action: MyAction) => MyAction;

Then you can use your strict MyDispatch in place of Dispatch anywhere and it will type-check correctly.

IMO if we add type parameters here, we'd have to write Dispatch<any> most of the time, because concrete type constraints depend on the middleware(s) you use.

I see how your proposal can be useful: if we put

type Dispatch<A, O> = (action: A) => O;

Then original Store definition (no middleware) would be:

interface Store<S> { dispatch: Dispatch<Action, Action>; }

Then we can strengthen Middleware type something like:

interface Middleware { <S, A, O>(api: MiddlewareAPI<S>): <D extends Dispatch<any, any>>(next: D) => D | Dispatch<A, O>; }

Thus we could always have strong typings for dispatch after all store enhancers were applied.
I need to experiment with this a bit.

Here's what I've come up with:

type StoreEnhancer<NewDispatch extends Dispatch<any, any>> = <D extends Dispatch<any, any>>(next: StoreCreator<D>) => StoreCreator<D | NewDispatch>;

It takes store creator with original dispatch and returns one where dispatch is either original or new.

But I couldn't get it to work with enhancers that don't add new dispatch signature, e.g. logger middleware:

const logger: Middleware</* ? */> = ({getState}) => { return <D extends Dispatch<any, any>>(next: D) => (action: /* ? */) => { console.log('will dispatch', action) let returnValue = next(action) console.log('state after dispatch', getState()) return returnValue } }

That's fine for default dispatch (no middleware):

type DefaultDispatch = <A extends Action>(action: A) => A;

The problem here is that dispatch doesn't always return its input. Consider redux-thunk:

store.dispatch(dispatch => 42) // returns 42

After applying thunk middleware dispatch gets type:

type ThunkDispatch = <O>(thunk: (dispatch, getState) => O) => O; typeof store.dispatch == DefaultDispatch | ThunkDispatch;

Things get worse when we try to define types for thunk arguments. In case of single thunk middleware it is obviously DefaultDispatch:

type ThunkDispatch = <O, S>(thunk: (dispatch: DefaultDispatch, getState: () => S) => O) => O;

But what if we had e.g. Promise middleware in front of thunk middleware? We should be able to dispatch promises from thunk:

type PromiseDispatch = <P extends Promise<any>>(promise: P): P; type ThunkDispatch = <O, S>(thunk: (dispatch: DefaultDispatch | PromiseDispatch, getState: () => S) => O) => O;

This means that thunk middleware should know about previously applied middlewares.

Tricky situation - JS (and other dynamically typed langs) encourages to build structures that accept anything and handle type inside (runtime reflection) while static typing is about splitting it to handle different inputs/outputs in separate functions/methods.

Thunk (and probably many other) middleware is so elastic, that best solution is to use just:

interface Dispatch extends Function { <A>(action: A) => A; <A, B>(action: A) => B; }

And use it with thunk:

const dispatch: Dispatch; … … dispatch<any>() …

Also consider this:

type ThunkDispatch = <O, S>(thunk: (dispatch: DefaultDispatch | PromiseDispatch, getState: () => S) => O;

is exactly same as:

type Thunk<S, O> = (dispatch: Dispatch, getState: () => S) => O; type ThunkDispatch = <S, O>(thunk: Thunk<S, O>) => O;

Which could be replaced with:

type ThunkDispatch = <Th, O>(thunk: Th) => O; // Just set type parameter `Th` as `Thunk<SomeState, TheOutput>` and `O` as `Output`

Which is exactly same as second overload here (:

interface Dispatch extends Function { <A>(action: A) => A; <A, B>(action: A) => B; }

Proposed promise dispatch is actually dispatch:

type PromiseDispatch = <P extends Promise<any>>(promise: P): P; // what is const dispatch: Dispatch; … dispatch<Promise<any>>(promise);

It makes more sense for me now. Thanks.
So basically we don't constraint types of dispatch argument and return value, but add ability for user to specify them if they want?

Right. I think it's the best we can do - will satisfy both strict typing freaks (like me) and elasticity lovers. I think the overloaded one does the job in a best possible way:

interface Dispatch extends Function { <A>(action: A): A; <T, O>(action: T): O; }

ulfryk · 2016-02-17T14:56:37Z

Middleware definition below seems to be enough, but…

interface Middleware<S> extends Function { (store: MiddlewareAPI<S>): (next: Dispatch) => Dispatch; }

It actually does not return a dispatch but function mapping input of type A to output of type B:

interface Middleware<S, A, B> extends Function { (store: MiddlewareAPI<S>): (next: Dispatch) => (action: A) => B; }

But in this case Middleware will always have to be parametrised with both type parameters. We can avoid this ( but I'm NOT sure if we should ) in the same manner as with Dispatch:

interface Middleware extends Function { <S, A, B>(store: MiddlewareAPI<S>): (next: Dispatch) => (action: A) => B; }

It's not always so easy to add static type definitions to code written in dynamically typed language… ;)

Let's try to implement thunk middleware in TypeScript as an example. Start without any types:

const thunkMiddleware = ({dispatch, getState}) => (next) => (action) => { return typeof action === function ? action(dispatch, getState) : next(action) }

Now what types can we add here? Keep in mind that there may me other middlewares applied before thunk, so dispatch here can potentially accept anything, e.g. promises. Same for next, same for action.
Middleware is standalone and doesn't know anything about dispatch type prior to when it was applied.

// in our typings interface Middleware<S, A, B> extends Function { (store: MiddlewareAPI<S>): (next: Dispatch) => (action: A) => B; }

import { MyState } from './wherever-my-state-is-declared' type ThunkAction = ((d: Dispatch, gs: () => MyState) => ThunkAction) | Object; const thunkMiddleware: Middleware<MyStore, ThunkAction, ThunkAction> = ({dispatch, getState}) => (next) => (action) => { return typeof action === function ? action(dispatch, getState) : next(action) }

Does it do the job ?

It shows that elasticity of thunkMiddleware stays in oposition to type safety. Anyway it can be always done in that way:

import { MyState } from './wherever-my-state-is-declared'; const thunkMiddleware: Middleware<MyStore, any, any> = ({dispatch, getState}) => (next) => (action) => { return typeof action === function ? action(dispatch, getState) : next(action) }

;)

The problem is — thunkMiddleware is standalone and it can't have knowledge of what MyStore is.

ulfryk · 2016-02-16T16:07:58Z

It's not a class because you can not import it from Redux (or 'redux') lib…

Trying this:

import { Store } from "redux"; const myStore = new Store({myStorKeys:andValues});

or just

const myStore = new Redux.Store({myStorKeys:andValues});

will compile but throw an error in runtime - this is makes static typing a bit useless :(

Correct. Not sure how it became a class here.

ulfryk · 2016-02-18T09:58:52Z

Action creators:

I think that overloading is much better than union:

// or maybe "<A extends Action>" but due to middleware issues better without "extends Action" export interface ActionCreator<A> extends Function { (...args: any[]): A; } export interface ActionCreatorsMapObject { [key: string]: <A>(...args: any[]) => A; } export interface ActionCreatorsBinder { <A>(actionCreator: ActionCreator<A>, dispatch: Dispatch): ActionCreator<A>; <M extends ActionCreatorsMapObject>(actionCreators: M, dispatch: Dispatch): M; (actionCreators: ActionCreatorsMapObject, dispatch: Dispatch): ActionCreatorsMapObject; } export function bindActionCreators: ActionCreatorsBinder;

I've tested it with such piece of useless code:

const oneCreatorA = bindActionCreators<Action>(a => a, store.dispatch); const oneCreatorB = bindActionCreators(oneCreatorA, store.dispatch); const oneCreatorC = bindActionCreators(oneCreatorB, store.dispatch); interface Ott extends ActionCreatorsMapObject { one: IActionCreator<Action>; two: IActionCreator<Action>; three: IActionCreator<Action>; four: IActionCreator<Action>; } const xCreatorA = bindActionCreators({ one: a => a, two(b: Action) {return b;}, three: oneCreatorA }, store.dispatch); const cMap: Ott = { one: a => a, two(b: Action) {return b;}, three: oneCreatorA, four: oneCreatorC }; const xCreatorB: ActionCreatorsMapObject = bindActionCreators(xCreatorA, store.dispatch); const xCreatorC: Ott = bindActionCreators(cMap, store.dispatch);

export interface ActionCreatorsBinder { <A>(actionCreator: ActionCreator<A>, dispatch: Dispatch): ActionCreator<A>; <M extends ActionCreatorsMapObject>(actionCreators: M, dispatch: Dispatch): M; (actionCreators: ActionCreatorsMapObject, dispatch: Dispatch): ActionCreatorsMapObject; }

Third overload seems redundant here, we can omit type parameter in second overload and it will be inferred as ActionCreatorsMapObject.

Also consider the difference between

<A>(actionCreator: ActionCreator<A>, dispatch: Dispatch): ActionCreator<A>;

and

<A extends ActionCreator<any>>(actionCreator: A, dispatch: Dispatch): A;

I guess the latter is stronger because let's you constraint not only return type of ActionCreator, but its full signature including argument types.

Second one here:

<A extends ActionCreator<any>>(actionCreator: A, dispatch: Dispatch): A;

is not typesafe as it enforces any.

I think we should find better way…

@aikoven also you said

Third overload seems redundant here, we can omit type parameter in second overload and it will be inferred as ActionCreatorsMapObject.

And that is great :)
It gives possibility to ignore type parameter if one chooses straight ActionCreatorsMapObject.

<A extends ActionCreator<any>>(actionCreator: A, dispatch: Dispatch): A;

is not typesafe as it enforces any.

I'm not sure I understand. This signature allows doing

bindActionCreators<ActionCreator<MyAction>>(...)

and even

bindActionCreators<(text: string) => MyAction>(...)

So type parameter is not enforced.

In contrast, if we used this signature:

<A>(actionCreator: ActionCreator<A>, dispatch: Dispatch): ActionCreator<A>;

to bind action creator of type (text: string) => MyAction, then bindActionCreators would return value of type (...args: any[]) => MyAction, effectively erasing constraints on its arguments.

Also, I found that we don't cover cases when bindActionCreators argument and return value have different types, e.g. if action creator returns thunk, then bound action creator will return what thunk returned.

Yeah, you're right. My mistake:

<A extends ActionCreator<any>>(actionCreator: A, dispatch: Dispatch): A;

Is totally ok.

Also, I found that we don't cover cases when bindActionCreators argument and return value have different types, e.g. if action creator returns thunk, then bound action creator will return what thunk returned.

So maybe third overload:

<A extends ActionCreator<any>, B extends ActionCreator<any>>( actionCreator: A, dispatch: Dispatch ): B;

ulfryk · 2016-02-17T15:02:35Z

Maybe it can be even better if we decide what should be the input type of composed function:

export function compose<R, I>(fn1: (arg: any) => R, ...functions: Function[]): (arg: I) => R; // I for input, R for Result

-Original file line number
+Diff line change
@@ -0,0 +1,51 @@
+    export interface ActionCreator {
+      (...args: any[]): any;
+    }
+    export type Reducer<S> = (state: S, action: any) => S;
+    export type Dispatch = (action: any) => any;
+    export interface MiddlewareAPI<S> {
+      dispatch: Dispatch;
+      getState: () => S;
+    }
+    export interface Middleware {
+      <S>(api: MiddlewareAPI<S>): (next: Dispatch) => Dispatch;
+    }
+    export class Store<S> {
+      dispatch: Dispatch;
+      getState: () => S;
+      subscribe: (listener: () => void) => () => void;
+      replaceReducer: (reducer: Reducer<S>) => void;
+    }
+    export type StoreCreator<S> = (reducer: Reducer<S>, initialState?: S) => Store<S>;
+    export type StoreEnhancer = <S>(next: StoreCreator<S>) => StoreCreator<S>;
+    export function createStore<S>(reducer: Reducer<S>, initialState?: S,
+                                   enhancer?: StoreEnhancer): Store<S>;
+    export function bindActionCreators<T extends ActionCreator|{[key: string]: ActionCreator}>(actionCreators: T, dispatch: Dispatch): T;
+    export function combineReducers<S>(reducers: {[key: string]: Reducer<any>}): Reducer<S>;
+    export function applyMiddleware<S>(...middlewares: Middleware[]): StoreEnhancer;
+    // from DefinitelyTyped/compose-function
+    // Hardcoded signatures for 2-4 parameters
+    export function compose<A, B, C>(f1: (b: B) => C,
+                                     f2: (a: A) => B): (a: A) => C;
+    export function compose<A, B, C, D>(f1: (b: C) => D,
+                                        f2: (a: B) => C,
+                                        f3: (a: A) => B): (a: A) => D;
+    export function compose<A, B, C, D, E>(f1: (b: D) => E,
+                                           f2: (a: C) => D,
+                                           f3: (a: B) => C,
+                                           f4: (a: A) => B): (a: A) => E;
+    // Minimal typing for more than 4 parameters
+    export function compose<Result>(f1: (a: any) => Result,
+                                    ...functions: Function[]): (a: any) => Result;

-Original file line number
+Diff line change
@@ Expand Up / @@ -4,6 +4,7 @@ @@
       "description": "Predictable state container for JavaScript apps",
       "main": "lib/index.js",
       "jsnext:main": "es/index.js",
+      "typings": "./index.d.ts",
       "files": [
         "dist",
         "lib",
@@ Expand Down @@

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add TypeScript definitions #1413

Diff view

Diff view

There are no files selected for viewing

ulfryk Feb 16, 2016

aikoven Feb 17, 2016

aikoven Feb 17, 2016

ulfryk Feb 17, 2016

aikoven Feb 17, 2016

aikoven Feb 17, 2016

aikoven Feb 17, 2016

aikoven Feb 17, 2016

ulfryk Feb 17, 2016

ulfryk Feb 17, 2016

aikoven Feb 18, 2016

ulfryk Feb 18, 2016

ulfryk Feb 17, 2016

aikoven Feb 17, 2016

ulfryk Feb 17, 2016

ulfryk Feb 17, 2016

aikoven Feb 18, 2016

ulfryk Feb 16, 2016

aikoven Feb 17, 2016

ulfryk Feb 18, 2016

aikoven Feb 18, 2016

aikoven Feb 18, 2016

ulfryk Feb 18, 2016

ulfryk Feb 18, 2016

aikoven Feb 18, 2016

ulfryk Feb 18, 2016

ulfryk Feb 17, 2016

Add TypeScript definitions #1413

Add TypeScript definitions #1413

Diff view

Diff view

There are no files selected for viewing

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Action creators:

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment