Proposal: react-router-mobx

[maxdeviant]

During an attempted upgrade to react-router v4 in a MobX codebase, I encountered the blocked updates issue. Obviously this is a bit of a deal breaker, since it would mean wide-sweeping changes to make all of the observers aware of location changes.

I have seen it hinted at in a couple of places that react-router-redux has a way around this in v5. I think it would be beneficial if this same fix/methodology could be brought to those of us using MobX.

I can see about getting a PR ready once react-router-redux v5 gets closer to release, but I just wanted to get this idea out there.

I think having first-class MobX support like we have for Redux would go a long way in bringing the community together around the coolest router 😎

[maxdeviant]

There is also some good discussion over in the Redux Integration (#4668) PR which may be relevant.

[agundermann]

As far as I can tell, the primary goal of react-router-redux is not to work around the blocked updates issue, but to integrate react-router with redux by syncing the router location with the redux store. I don't know mobx enough to say if that's possible/practical there, too. But if you're just concerned about the blocked updates, you don't really need an extra library for this; you can simply compose the HoCs/decorators yourself:

// observerWithRouteProps.js
import {observer} from 'mobx-react';
import {withRouter} from 'react-router';

export default Component => withRouter(observer(Component));

And then just use that function instead of observer from react-mobx. This should work with all HoCs/decorators that respect the prop updates of the component.

[timdorr]

react-router-redux does nothing with connected components or blocked updates. It's simply for synchronization of location into state.

If you mean the changes on react-redux, that is a separate thing were doing here: reduxjs/react-redux#625

Anything that gets around blocked updates is either something to be solved by the library that's blocking, or is something we would solve in a much more generic implementation than just for MobX's use.

[maxdeviant]

@timdorr Thanks for the info!