Comment by acemarke | Hacker News Reader

Comment by acemarke | Hacker News Reader

Parent Full thread

FWIW, I'm a Redux maintainer, and I personally have never understood the point of trying to limit what actions are being dispatched. As long as your reducers and action creators are well typed, it shouldn't matter what other actions might be sent through.

On that note, our new Redux Toolkit package is written in TS, and designed to work great in TS apps with a minimal amount of type declarations needed. Really just declare the type of the action in the reducer, and get everything else for free. The new React-Redux hooks API is also a lot easier to use with TS as well.

I showed how to use both of those in the Redux Toolkit "Advanced Tutorial" docs page:

https://redux-toolkit.js.org/tutorials/advanced-tutorial

On a related note, I also recently put up a long blog post detailing my own journey learning and using TS, as both a lib maintainer and an app developer, with my takeaways on the pros and cons of using TS:

https://blog.isquaredsoftware.com/2019/11/blogged-answers-le...

> I personally have never understood the point of trying to limit what actions are being dispatched. As long as your reducers and action creators are well typed, it shouldn't matter what other actions might be sent through.

The value comes when you consider what happens if a reducer (or saga or whatever) is updated in a breaking way (or removed wholesale).

Example: consider a scenario where you use `connected-react-router`, your codebase fills up with history actions being dispatched, then one day you remove `connected-react-router`, or its major version is updated and introduces some breaking change.

If you have a union type that includes all your own actions plus the `LocationChangeAction` from connected-react-router (and you use is consistently - e.g. your components take `Dispatch<YourAction>`) then you'll learn about the breaking change when your app fails to compile.

The alternative is you catch it later than compile-time, at worst _much_ later.

You might decide that the overhead in this scenario isn't worth it, and that's your call to make (I believe it is worth it) but hopefully this gives an idea of the point.

Reply on news.ycombinator.com