Consider removing redux-typed #1309

New Issue

fergalmoran · 2025-08-09T17:19:38Z

fergalmoran commented

2025-08-09 17:19:38 +00:00

Originally created by @SteveSandersonMS on 10/17/2016

@emzero and others have stated a preference for removing the redux-typed dependency from ReactReduxSpa and instead only making use of the native type information provided by @types/react-redux etc.

You might be wondering why redux-typed was created, and why it's only (apparently) used in these project templates, not by the wider Redux community. redux-typed was created about a year ago, because:

At that time, Redux didn't natively offer any TypeScript type hints
At that time, Redux's APIs were seriously mismatched with the way TypeScript handles strong typing. In particular, Redux largely expected developers to construct props for components by merging together various other objects at runtime, e.g., like this. Because of this runtime-merging approach, there was no actual statically-determined type information that would give good completion hints, e.g., on this.props inside a component. As far as I can tell, the Redux community wasn't widely using TypeScript at that time.

So, redux-typed addressed this by (1) obviously providing TypeScript type hints, and (2) by an admittedly non-obvious but quite effective use of TypeScript's inference features and typeof operators to allow type info to flow directly from your stores/reducers/etc via the provide mapping into dynamically-constructed component-props types. It manages to create implicit types that combine all the properties from your stores/reducers/etc, in the same way that will happen at runtime.

However, I haven't personally been promoting the use of redux-typed via all the usual marketing channels (blog posts, conference talks, etc.), and not surprisingly, the library hasn't become hugely widespread without that sort of promotion. Very few people really know what it's doing or what benefits it offers.

Now as of October 2016, partly the original issues have subsided. For (1), there's now @types/react-redux etc., which covers most of the basics. But for (2), as far as I can tell, things have only improved slightly - examples like this suggest you still have to manually create TypeScript interfaces that duplicate the type information from your stores/actions/etc.

What we need to decide now is:

Can we remove redux-typed? It would be great if we could, because like @emzero and others have pointed out, it's pretty non-standard in the Redux community, and may be a barrier for people trying to make sense of code they see elsewhere. Even if redux-typed still has benefits, it's not clear that they are so essential it's worth the cost of having something unusual in the templates.
Or, do we decide that redux-typed is so much better than the alternative that it has to stay? This approach is only really viable if some people step up to own its maintentance and promotion within the Redux community. I don't expect to have capacity to do that myself.

If we go for option 1, then is somebody (@emzero?) willing to propose a PR that removes it, and updates the ReactReduxSpa template to contain the same functionality but without that dependency? I know the code will end up being more verbose because it will probably become necessary to specify things to TypeScript that redux-typed would have done automatically. But can the code still be straightforward enough for newcomers to work with?

*Originally created by @SteveSandersonMS on 10/17/2016* @emzero and others have stated a preference for removing the `redux-typed` dependency from `ReactReduxSpa` and instead only making use of the native type information provided by `@types/react-redux` etc. You might be wondering why `redux-typed` was created, and why it's only (apparently) used in these project templates, not by the wider Redux community. `redux-typed` was created about a year ago, because: 1. At that time, Redux didn't natively offer any TypeScript type hints 2. At that time, Redux's APIs were seriously mismatched with the way TypeScript handles strong typing. In particular, Redux largely expected developers to construct `props` for components by merging together various other objects at runtime, e.g., [like this](https://github.com/reactjs/react-redux/blob/master/docs/api.md#inject-todos-and-all-action-creators-addtodo-completetodo--as-actions). Because of this runtime-merging approach, there was no actual statically-determined type information that would give good completion hints, e.g., on `this.props` inside a component. As far as I can tell, the Redux community wasn't widely using TypeScript at that time. So, `redux-typed` addressed this by (1) obviously providing TypeScript type hints, and (2) by an admittedly non-obvious but quite effective use of TypeScript's inference features and `typeof` operators to allow type info to flow directly from your stores/reducers/etc via the `provide` mapping into dynamically-constructed component-props types. It manages to create implicit types that combine all the properties from your stores/reducers/etc, in the same way that will happen at runtime. However, I haven't personally been promoting the use of `redux-typed` via all the usual marketing channels (blog posts, conference talks, etc.), and not surprisingly, the library hasn't become hugely widespread without that sort of promotion. Very few people really know what it's doing or what benefits it offers. Now as of October 2016, partly the original issues have subsided. For (1), there's now `@types/react-redux` etc., which covers most of the basics. But for (2), as far as I can tell, things have only improved slightly - examples [like this](https://github.com/rangle/typescript-react-redux-example/blob/master/src/components/counter/index.tsx) suggest you still have to manually create TypeScript interfaces that duplicate the type information from your stores/actions/etc. What we need to decide now is: 1. **Can we remove `redux-typed`?** It would be great if we could, because like @emzero and others have pointed out, it's pretty non-standard in the Redux community, and may be a barrier for people trying to make sense of code they see elsewhere. Even if `redux-typed` still has benefits, it's not clear that they are so essential it's worth the cost of having something unusual in the templates. 2. **Or, do we decide that `redux-typed` is so much better than the alternative that it has to stay?** This approach is only really viable if some people step up to own its maintentance and promotion within the Redux community. I don't expect to have capacity to do that myself. If we go for option 1, then is somebody (@emzero?) willing to propose a PR that removes it, and updates the ReactReduxSpa template to contain the same functionality but without that dependency? I know the code will end up being more verbose because it will probably become necessary to specify things to TypeScript that `redux-typed` would have done automatically. But can the code still be straightforward enough for newcomers to work with?

fergalmoran closed this issue

2025-08-09 17:19:38 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/JavaScriptServices#1309