Ditching Subscriptions in React Router
Paul Sherman

Subscriptions in React Redux do work

Thank you for writing this explanation, but I still don’t get why React Redux can get away with subscription model and React Router not. They seem so similar on the surface: In the end both are just objects (store & history) with a callback telling when it’s internal state has changed. Maybe I’m missing something really relevant here?

AFAIK React Redux do not have any of the drawbacks you mention.

Unnecessary renders

This did not come easily thou. It had bugs and I had my own battles with it. Also initially batching Redux updates with ReactDOM.unstable_batchedUpdates() was required to avoid the extra rerenders and other bugs with nested connect()s but I was later fixed by jimbolla using a very clever method to dispatch the changes: https://github.com/reactjs/react-redux/issues/407#issuecomment-227566601. Here’s a working link to the Subscription.js and here’s the relevant part for connect().

This sure fits your definition a “trick solution” but with the enormous user base of React Redux it is an extremely battle tested one.

Stale Context

React Redux solves this by sending the state in the store container. The store container does not ever change — only the state inside it. This means that the shouldComponentUpdate() methods never have to care about it because the identity of it stays the same and the connect()s can just get the most recent state with store.getState().

Discussion continues at https://github.com/ReactTraining/react-router/issues/4671