Typescript examples

[ashishsc]

I think we should try writing the example in typescript. There's some friction you run into when defining action creators unless you define it the way redux-loop is expecting it (using the ActionCreator type, etc.) I'll try and post a concrete issue of what I'm facing here in a bit. @willisplummer since you added the definitions, do you have any sample code using redux-loop in a ts project?

[willisplummer]

Yeah definitely. I'll open a PR tomorrow or later this week. Interested to see what you're running into though!

[bdwain]

Agreed. This is also related to #158. I think that's probably the next big task ahead of us. It would really lower the barrier to entry for people.

[ashishsc]

Ok so, first a question about the type for Cmd.run:

  static readonly run: <A extends Action>(
    f: Function,
    options?: {
      args?: any[];
      failActionCreator?: ActionCreator<A>;
      successActionCreator?: ActionCreator<A>;
      forceSync?: boolean;
    }
  ) => RunCmd<A>;

I'm getting type errors here because my fail and success action don't create the same action. Shouldn't the actual type be

  static readonly run: <A extends Action, F extends Action>(
    f: Function,
    options?: {
      args?: any[];
      failActionCreator?: ActionCreator<F>;
      successActionCreator?: ActionCreator<A>;
      forceSync?: boolean;
    }
  ) => RunCmd<A>;

I could be wrong because this seems like a cascading problem as we would need to change all of

export type CmdType<A extends Action> =
  | ActionCmd<A>
  | ListCmd<A>
  | MapCmd<A>
  | NoneCmd
  | RunCmd<A>
  | BatchCmd<A>
  | SequenceCmd<A>;

to

export type CmdType<A extends Action, F extends Action> =
  | ActionCmd<A,F>
  | ListCmd<A,F>
  | MapCmd<A,F>
  | NoneCmd
  | RunCmd<A,F>
  | BatchCmd<A,F>
  | SequenceCmd<A,F>;

[ashishsc]

Another issue:

export type ReducerMapObject<S, A extends Action = AnyAction> = {
    [K in keyof S]: LoopReducer<S[K], A>
};

declare function combineReducers<S, A extends Action = AnyAction>(
    reducers: ReducerMapObject<S, A>,
): LiftedLoopReducer<S, A>;

declare function mergeChildReducers<S, A extends Action = AnyAction>(
    parentResult: S | Loop<S, A>,
    action: AnyAction,
    childMap: ReducerMapObject<S, A>,
): Loop<S, A>;

including redux-loop in my project gives me errors:

ERROR at [repo]/node_modules/redux-loop/index.d.ts(123,50): 
TS1005: ',' expected.
ERROR at [repo]i/node_modules/redux-loop/index.d.ts(127,54): 
TS1005: ',' expected.
ERROR at [repo]/node_modules/redux-loop/index.d.ts(128,13): 
TS2314: Generic type 'ReducerMapObject' requires 3 type argument(s).
ERROR at [repo]/node_modules/redux-loop/index.d.ts(131,57): 
TS1005: ',' expected.
ERROR at [repo]/node_modules/redux-loop/index.d.ts(134,13): 
TS2314: Generic type 'ReducerMapObject' requires 3 type argument(s).

In might be a good idea to start actually rewriting the codebase in typescript as well to catch these sorts of things. I don't think we have any coverage around our typings right now, do we? otherwise this would have caught it, right?

[bdwain]

Having played around with typescript a bit to work with the typings, I feel like rewriting everything with typescript might make it harder for people who don't use typescript to contribute. That, combined with the effort it will takes makes me think it's probably not worth it.

I think we could improve our tests to catch issues with our typings though for sure. We really need to improve the examples folder and a few different kinds in there, including a typescript project. I think that'd be really helpful.

[gniquil]

@ashishsc For you first issue, Cmd.run, I've run into this as well. The solution is to make your action creators return the union Action type. That should solve your problem. However, if you want to adopt this approach, your action creators need to be able to import the root Action type, which implies that action creators need to exist completely separately from your action definitions. This is generally different from the way people code in normal javascript (say duck style).

Step back a bit, and being a super fan of Elm (but not be able to use it for various reasons), adopting this library with typescript, you should stick to the Elm architecture as much as possible. Strict typing points out many issues exist in the normal redux architecture. So, decompose your app into multiple sub reducers and use Cmd.map to wrap actions (generally the "fractal pattern"). At work, once we started doing this, most of our typing related issues are gone.

[ashishsc]

@gniquil I am also a huge fan of elm, hence why I came to loop. I am not sure that our action creators should return the union Action type. I take advantage of the fact that the creators can return a specific kind of action. Although now that you mention it, that's similar to how in elm, the view functions return Html Msg where Msg is a union type. @willisplummer was that the intent?

@bdwain I don't it would be too bad to rewrite in typescript since we already have the typings written, we just need to annotate our actual functions with them, but I do agree that it would make it harder for non-tsers to contribute. I also agree that we really need an example of using typescript in the examples folder. I could take that on after I get this working.

[willisplummer]

Yeah, @gniquil has the right idea here. Take a look at the tests i wrote for the typescript definitions to get a sense of how this is working: https://github.com/redux-loop/redux-loop/blob/master/test/typescript/loopReducer.ts

I agree that a TypeScript rewrite wouldn't actually be very hard to do. Adding function annotations is generally fairly straightforward, and it would give us more confidence that our types were accurate. It's easy for a declaration file to get out of sync with the JavaScript code if someone makes a change and doesn't remember to update the types, and actually using .ts files would prevent this possibility.

The ReducerMapObject errors you're running into are weird to me. AFAICT the compiler should be able to infer the type of K from S, right? (cc @jaredklewis )

[willisplummer]

@ashishsc I'm not sure what an action creator would return if not the union type of all the possible actions for a given reducer or more broadly redux's AnyAction type?

[willisplummer]

Another argument that I see for pursuing a TypeScript rewrite is that defining your API's can quickly make architectural complexity more apparent. (When a function accepts weird union types or is difficult to type, that's generally a good indicator that it's attempting to do too much).

[gniquil]

Like Cmd.run. Wouldn't it be awesome if it type checks the args against effect func arguments, and resolved promise wrapper against success/fail actionCreators. Too bad typescript can't do the following

Cmd.run: <T, R, A>(f: (...args: T) => Promise<R>, { args: T, successActionCreator: (result: R) => A, failActionCreator: (error: any) => A }): CmdType<...>

At work we reexport a more restricted version of Cmd.run, forcing effect func to only take 1 arg (and completely forbid getState and dispatch).

[ashishsc]

I take issue with the way the Redux uses AnyAction, I like to do in my reducers and subreducers

switch(action.type)
    case FOO: {
         ....
    },
    ...,
    default:
        thisFailsAtCompileTime(action)

but with the way redux defines AnyAction this isn't possible.

In order to address this in our work project, we instead define our own type for the reducer:

import { Loop as ConstructLoopType } from 'redux-loop';
type Loop = ConstructLoopType<State,Action> | State;