Most of my pain with the React ecosystem happened when people kept rebuilding react-router every 6 months. I managed one upgrade, but after that we gave up and stuck with the old version because it worked well for our purposes.
Certainly, the React ecosystem is full of stuff that changes gratuitously --- but my feeling is the rate of change on that stuff is usually inversely proportional to its utility. For instance: I'm not entirely sure why anyone uses an add-on router library.
Asking because I'm just getting into React, and not really clear on best practice yet. You seem to know a thing and have an opinion; will you share them?
Yes. There's a continuum of routing needs in React apps. If you're not strictly an SPA, you don't need it at all; the browser already does it for you. For a lot of straightforward SPAs, the most basic "display this component based on current tab" works. Past that, a "real router" is just a small piece of code that looks at window.location to decide which component to render, and a Link that knows how to use the history API.
I don't understand why people bloody their foreheads on react-router. The thing it is doing is simple enough to re-do by hand in any application.
You see the same thing with flux implementations: flux libraries change rapidly, because there's not that much to the underlying concept and it's easy to mess with them. But most apps probably don't need flux at all.
You can do this, but routes-per-page with parameters and working back/forward buttons with no serious deps is literally something like 15 lines of code. I think more people should just hack their own router together before introducing a dep for it.
It might be an interesting academic problem to chew on but there's edge cases there with history, route parsing, nested routes etc that are beyond beginner level I would argue. There's something to be said for using a massively popular lib like React Router that the rest of the community is battle testing for you.
* History: on modern browsers this is ~5 lines of code? Pushing URLs with pushState, triggering PopState events, and binding a popstate handler to trigger render changes.
* Route parsing: just use pathToRegexp. Yes, it's a dep, but it's an easy, well-understood one that does one simple thing you can get your head around. Or: don't use route paths with parameters at all (it's overkill for a lot of applications) and just use a trivial switch statement.
* Nested routes: why bother? The routes we're talking about are totally artificial. Having a formal, declarative route system in the first place is already a lot of "engineering". Just define your routes so they don't do that.
My argument is that the hand-hacked system that does this will be approximately as capable, future-proof, reliable and performant as the first production system anyone builds with react-router will be, the learning curve is shorter, the code you're building won't have APIs shift out from under it, and the final system will be trivial to port to react-router once that library stabilizes, if you ever wanted to bother doing that.
