Support for typed actions (Typescript)

[nickknw]

Related to these two issues:

• Support for typed Actions #355
• Relax the constraint on actions #437

Hi Dan,

The company I am with is using Redux as well as Typescript, and we would like to add some additional compile-time guarantees to our actions. Currently this isn't possible because of the restriction that actions must be plain objects. You said that this is because 'record/replay and associated features won't work with an action class' and I get that those are valuable features and don't want to lose them. But I had code using Typescript classes that (when the redux devtools were enabled) could still record, cancel and replay actions just fine (using the code I posted in issue 355).

When I remove the devtools I just get errors from that check that actions are plain objects and execution stop there. To me it seems like it is too strict, checking more than is really required. I would much rather have a check that requires that the actions are serializable. I know performance is a concern - IMO it shouldn't have to guarantee/prove they are serializable, just check that the action objects themselves say that they are, and then trust them.
(Not sure why the check doesn't also fail when devtools are enabled - maybe you can shed light on that).

I would really like to be able to leverage the advantages of both Typescript and Redux. Hope you can help me (and others using both of these tools) arrive at a solution.

I also want to reiterate that (as much as I wish it were otherwise!) Typescript does not have discriminated unions, so solutions based on that approach will not work.

Thank you!

[gaearon]

Does TypeScript let you type-check shapes of plain objects instead of defining classes?
My only issue is with using instances of classes for actions.

Wouldn't TypeScript interfaces be enough to strongly type plain object actions?

[nickknw]

Almost - the problem with those is that they only exist at compile-time. So the reducer will have no way to tell which incoming action is of which interface. ...Unless I keep the 'type' property on each action and then manually cast them after checking that property. And at that point I'm not getting any extra type-safety over just treating them as plain objects.

[alitaheri]

@nickknw Well there can be no way to strong type those actions! I mean it wouldn't be possible even if it was C#! It's just how the architecture is, it doesn't have anything to do with redux. I my self use redux with typescript too. And best I could come up with was having interfaces with the same name as my actionTypes, keep the interfaces and constants in the same place, enforce my actionCreators to respect the typings and cast inside the reducers. It's not so hard to maintain and it gives me the type safety I need with clear intentions why the interfaces exist. I would suggest you to consider this approach, it worked for me 😁 and my project is kinda huge :D

[gaearon]

You said that this is because 'record/replay and associated features won't work with an action class' and I get that those are valuable features and don't want to lose them. But I had code using Typescript classes that (when the redux devtools were enabled) could still record, cancel and replay actions just fine (using the code I posted in issue 355).

Yes but then if you use persistState() enhancer, serialize them, and later restore your state and deserialize them, they will no longer work because your code is relying on instanceof checks.

The “plain objects” isn't really the point. What we want to enforce is that you don't rely on actions being instances of specific classes in your reducers, because this will never be the case after (de)serialization.

[gaearon]

In other words, this is an anti-pattern:

function reducer(state, action) {
  if (action instanceof SomeAction) {
    return ...
  } else {
    return ...
  }
}

If we make it possible for TypeScript users, I know JavaScript users will be tempted and will abuse this because many people coming from traditional OO languages are used to writing code this way. Then they will lose benefits of record/replay in Redux.

One of the points of Redux is to enforce some restrictions that we find important, and that, if not enforced, don't allow for rich tooling later on. If we let people use classes for actions, they will do so, and implementing something like redux-recorder will be impossible because there's no guarantee people use plain object actions. Especially if boilerplate projects suddenly decide to adopt classes because “wow, it’s allowed now, it must be a great idea”.

[nickknw]

What we want to enforce is that you don't rely on actions being instances of specific classes in your reducers, because this will never be the case after (de)serialization.

I think this is where you lost me. I don't follow why serializing and deserializing an object necessarily means that it will lose its class-related information.

[gaearon]

let actions = [new SomeAction(), new OtherAction()];
let json = JSON.stringify(actions);
let revivedActions = JSON.parse(json);
// reducers no longer understand revivedActions because type info is stripped.

[gaearon]

Another reason why I don't want to allow people to create classes for actions is because this will encourage folks to

a) Create class hierarchies
b) Put logic there, e.g. “patch” method from #437 (comment)

Both are contrary to how I intend Redux to be used. However React showed that if you give people ES6 classes, they will use inheritance even when there are much better alternatives, just because it's so entrenched in software development. It's hard to let go of old habits unless you're forced to.

It's sad that TypeScript forces you to turn things you want to strongly type into classes, but I believe this to be a fault of TypeScript, not ours. As described in #992 (comment), I find casting to be the best solution we can offer. You can also publish redux-typescript-store project with createStore() that doesn't have this restriction, but I'm still not compelled to remove it.

[gaearon]

Finally: for the record, I'm not hatin' on classes.
That's not my point.

My only point is that actions should be passive descriptions of what happened. If we allow them to be class instances, people will build weird abstractions on top of actions with classes, and suffer as a result.

Do not want.

[nickknw]

Ahh okay, thank you for the example. I didn't realize that JSON.stringify discards prototype information. It doing that makes sense to me in retrospect, given the limitations of what JSON can store.

One of the points of Redux is to enforce some restrictions that we find important, and that, if not enforced, don't allow for rich tooling later on.

Yes, I get that, am on board with it, and don't want to compromise on the guarantees the tools can count on. I don't want to create class hierarchies or attach logic to classes, just want to be able to tell them apart at compile-time.

It's sad that TypeScript forces you to turn things you want to strongly type into classes, but I believe this to be a fault of TypeScript, not ours.

Interfaces work well enough for what they were designed for, but I agree it is unfortunate for this use case that they don't keep any type information around at runtime (or allow for a runtime check 'does this conform to this interface' in another way).

My only point is that actions should be passive descriptions of what happened.

100% agree with you here

If we allow them to be class instances, people will build weird abstractions on top of actions with classes, and suffer as a result.

Ugh, I suppose that's true too.

---

I still think there might be room for a middle ground here, with a slightly more flexible way of serializing actions. There's the 'reviver' and 'replacer' parameters for parse and stringify - maybe there is a way to create a serialization function that can preserve enough information for me to pass some basic type information through but also know enough about the structure to warn/error about the scenarios you want to prevent.

Would rather not go down the route of manually casting actions - I might if nothing else works out but at that point the types aren't adding a lot of value for the effort.

[nickknw]

And yes it would be nice if Typescript had more flexible typing options so that I didn't have to use classes but that isn't something I can realistically affect or count on changing any time soon.

[gaearon]

maybe there is a way to create a serialization function that can preserve enough information for me to pass some basic type information through but also know enough about the structure to warn/error about the scenarios you want to prevent.

This would involve user implementing functions that map type strings to classes which is pretty much manual casting all over again. And we don't want users to implement this sort of stuff to get record/replay working. This is another point of Redux: you get hot reloading, record/replay for free, without implementing serialize(), hydrate(), etc.

[nickknw]

This would involve user implementing functions that map type strings to classes which is pretty much manual casting all over again.

Ideally it would just involve implementing a pair of functions that do that, and then all the action classes would be implemented in a way that those functions could serialize them. So instead of possibly introducing human error once for each different action handled, it would just be once.

And we don't want users to implement this sort of stuff to get record/replay working.

Not what I was proposing - this could be something that is opt-in. If you don't need to do it everything works as normal. I understand you might not be enthusiastic about opening that can of worms. I don't mind digging into this at some point and see if I can find some way to preserve the type information I want without opening the door wide open for everything else.

This is another point of Redux: you get hot reloading, record/replay for free, without implementing serialize(), hydrate(), etc.

This is a great benefit of Redux and I wouldn't want to change that. But I would also love to get some compile-time guarantees for actions while using Redux.

[gaearon]

I don't want to change it in core for reasons above. As I said previously, please feel free to create redux-typescript package with TS-friendly version of createStore and (maybe?) other Redux functions. We don't intend to have breaking changes in Redux at this point so you shouldn't worry about keeping up with the API. And as long as the API matches, such custom store will work just fine. (And its implementation is tiny, check out createStore source).