This just showed up in my Google news feed (links to that other, often paywalled blogging site, but Bit is pretty good about offering their articles for free): Reach Router VS React Router. I'm pretty sure I've seen this before, but it's dated as published today (maybe a revision?).
The article offers a decent high-level comparison of the two, using the current stable v5 of React Router (though v6 is in beta and looming ever nearer), but it's the conclusion the author reaches which bugs me:
"So which routing library should you use for your React project? If you’re starting a clean, new project, I suggest you go with Reach Router because its code pattern is easier to understand with less boilerplate code to write."
In my opinion, this is short-sighted advice (given the context of today's publish date), and not in keeping with what both projects have been saying for some time now: That the two are merging, and React Router will be the surviving project.
For example:
- The Future of React Router and @reach/router (May 17th, 2019)
- The future of Reach Router and React Router (April 3, 2020, LogRocket Blog, not affiliated but coinciding with release of and detailing migration to RR v5.1)
- Reach vs react router v6? (Reach Router issue #354, Feb 5, 2020)
To be fair, Nathan (the author of the post in question, not the Nathan in the gifs) follows that up with:
"But if your app design includes an intricately complex routing with lots of nested routes, and you’re also planning to develop mobile apps with React Native, you may want to pick React Router."
Still, you shouldn't be recommending libraries, which specifically say they're going away, for new projects, regardless of how simple those projects may be.
Bonus
Since I code/architect a lot of single-codebase projects targeting six platforms with React Native (iOS, Android), Electron (Windows, Mac, Linux), and React Native Web (web, obviously, as well as the three aforementioned desktop platforms), I'll share how easy it can be to set up React Router as components you can import the same way to target all six.
With React Router v5:
// routing.web.js
export { BrowserRouter as Router, Switch, Route, Link, useHistory, useLocation, useParams, useRouteMatch } from 'react-router-dom';
// routing.native.js
export { NativeRouter as Router, Switch, Route, Link, useHistory, useLocation, useParams, useRouteMatch } from 'react-router-native';
// routing.electron.js
// If you prefer file-based routing to memory-based, use HashRouter instead of MemoryRouter
export { MemoryRouter as Router, Switch, Route, Link, useHistory, useLocation, useParams, useRouteMatch } from 'react-router-dom';
With React Router v6 beta:
// routing.web.js
export { BrowserRouter as Router, Routes, Route, Link, Navigate, Outlet, useNavigate, useLocation, useParams, usePrompt } from 'react-router-dom';
// routing.native.js
export { NativeRouter as Router, Routes, Route, Link, Navigate, Outlet, useNavigate, useLocation, useParams, usePrompt } from 'react-router-native';
// routing.electron.js
// If you prefer file-based routing to memory-based, use HashRouter instead of MemoryRouter
export { MemoryRouter as Router, Routes, Route, Link, Navigate, Outlet, useNavigate, useLocation, useParams, usePrompt } from 'react-router-dom';
If you look closely, the only differences are the .web.js/.native.js/.electron.js file extension prefix, the specific Router component imported (BrowserRouter for web, NativeRouter for native/mobile, and either MemoryRouter or HashRouter for Electron/desktop), and the module the components are imported from (react-router-dom for both web and Electron/desktop, react-router-native for native/mobile).
Top comments (1)
Yes, that's the point I'm making. React Router v6 isn't finalized, but the beta is already very stable and is what I'd recommend at this point over both Reach Router and React Router v5 for a project starting today.