Support for typed Actions

[razjel]

I'm using Redux alongside with TypeScript and I created my custom class Action and ActionCreator

//Action.ts
export default class Action
{
    public type:string;
    public data:any;

    constructor(type:string, data:any = null)
    {
        this.type = type;
        this.data = data;
    }
}

// PhotoActions.ts
export function processPhoto(photoData:PhotoData)
{
    return new Action(PROCESS_PHOTO, photoData);
}

When I try to dispatch this action I get error Actions must be plain objects. Use custom middleware for async actions. Is it really necessary for action objects to be plain objects?

[gaearon]

Yeah, record/replay and associated features won't work with an action class.
We don't want to encourage this so people don't lock themselves out of great features.

Does TypeScript support discriminated unions or something?
You could define Action as an object whose shape depends on type.

[cesarandreu]

Related: flux standard action

[razjel]

TypeScript has discriminated unions, so when I get some free time I will try to figure something out with it.

@cesarandreu is this flux standard action also related to actions in redux? Because in my actions instead of payload I name property data, will it break something?

[razjel]

Ok, I figured it out, I create plain object and cast it as my desired class, thanks to this I can get syntax checking with plain objects:

// PhotoActions.ts
export function processPhoto(photoData:PhotoData)
{
    return {
        type: PROCESS_PHOTO,
        data: photoData
    } as Action;
}

[gaearon]

is this flux standard action also related to actions in redux?

It's just a recommendation. You can follow it or ignore it.

Closing as the initial issue appears to be solved by casting.
(Discriminated unions should indeed be a better solution.)

[nickknw]

I am also using Redux with Typescript and trying to get some static typing guarantees on my actions.
Typescript supports union types, but doesn't support discriminated unions, so a solution based on that is a no go.

What I arrived at was something that looked like this:

ActionTypes.ts

export abstract class Action {
     // (For maximum compatibility with redux-logger and redux-devtools)
    get type(): string {
        return this.constructor.toString().match(/\w+/g)[1];
    }
}

export class UserInfoRequest extends Action { }

export class UserInfoSuccess extends Action {
    constructor(public data: any) { super(); }
}

Actions.ts

...
function loadUsersSuccess(responseData: any) : Object {
    return new ActionTypes.UserInfoSuccess(responseData.data);
}
...

UserManagementReducer.ts

... 
    if (action instanceof UserInfoSuccess) {
        // here I now get compile-time errors if I try to access
        // a nonexistent property of UserInfoSuccess (e.g. dtaa). Success!
        return convertIncomingUserData(action.data);
    } else {
        return state;
    }
...

The only problem is that I get the error Actions must be plain objects. Use custom middleware for async actions. Up above you say this is because otherwise it will break record/replay functionality. But this is actually still completely intact (as far as I can tell). When I add redux-logger and the devtools, I can still cancel the load action, see the data disappear, then replay it and see the data appear again. It all seems to work completely normally.

I would really like to be able to leverage the advantages of both Typescript and Redux. Any idea what is going on here? Is the 'plain object' check perhaps just too strict?

[gaearon]

Can you try using discriminated unions instead of classes?
Using class and instanceof seems like the wrong way to achieve type safety here.

[nickknw]

As far as I know Typescript does not support discriminated unions.

It supports union types, like these: http://blogs.msdn.com/b/typescript/archive/2014/11/18/what-s-new-in-the-typescript-type-system.aspx?PageIndex=3
But not discriminated unions / sum types: microsoft/TypeScript#186

As far as 'the wrong way to achieve type safety' goes - if discriminated unions were available I would use them! But we work with what we have, and this approach does give me type safety and compile-time checks.

[nickknw]

(realized I left it out of my initial post)
I also did try the casting solution and it does not work - even though plain objects can be casted to my defined classes the reducer still ends up receiving them as plain objects, so I cannot get a combination of compile-time safety with working runtime behaviour. I am guessing razjel was still switching on the type property in the reducer and didn't have compile-time checks on properties as a goal.

[gaearon]

See a workaround for TypeScript 1.6: #992 (comment)

[aikoven]

There is another approach for action typing: #992 (comment)