React Router 6
reactrouter.comUsually new versions excite me, but with React Router I can only wonder: how much of a re-write will I need to do?
Seriously, the upgrades are always such a massive pain.
The v5 -> v6 doc is already making me dizzy just from how long it is https://reactrouter.com/docs/en/v6/upgrading/v5
People should really take Next.js as an example here.
They make sure it's backwards compatible as much a possible and when it's not they provide a codemod or the app tells you what's wrong (and how to fix it!) when you try to run it.
If course the latter is hard/impossible with a lower level library like this but the former is def. possible.
Emotion css decided to rename/reshuffle all their packages and imports in v11 which was a massive pain, but with the provided codemod that migration was not too painful.
How is this sustainable?
Write fewer tests and change quickly.
> Write fewer tests
Sold.
Write end-to-end tests that test behavior instead of implementation.
I think it's time to start testing tests. The first test will be metrics how often tests are changed when the things they test are changed. If it's close at all to 1 to 1 then the test fails.
It is only sustainable for large businesses, which increasingly are the only businesses.
The author of react-query (one of my favorite libraries) also just released the beta of yet another router called React Location: https://react-location.tanstack.com/
I've used Reach Router in the past and it's also pretty nice, but I didn't see a reason to use it over React Router... https://reach.tech/router/
Wow, another library (react-location) that shows TypeScript as its primary documentation language. And I see more and more jobs hiring for TypeScript developers.
I see Microsoft's 3 E's campaign strongly in action with TypeScript.
For those who care about Corporate Ethics, please review Microsoft's: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis...
For that reason, I refuse to touch TypeScript libraries-- out of sheer anti-corporate-oligarchy ethical conviction.
Well, it's open source and they aren't going to extinguish JavaScript anytime soon. So I don't see how it would apply here.
Microsoft are actively hostile towards JavaScript now. I have been monitoring the progress of vscode's support for JavaScript and noticed that it now clearly a second class citizen. The TypeScript compiler now declares valid and working JavaScript as having errors, and these are displayed to the user in vscode. One example is the usePrevious hook as mentioned on the react website. If you mouse over its signature in vscode, you will see it is undefined -> undefined. This is because useRef() has no argument, and the generic type is inferred from this argument, and JavaScript has no way to do useRef<T>();
If you're going to about Microsoft's ethics, it's probably also necessary to complain about Facebook's ethics since they own React.
Vue has an official router library, but react seems to have multiple popular routing libraries. Reinventing the wheel much?
I've definitely found it a little weird how React doesn't have a more official routing library, especially since they are all so similar.
It feels like Next.js is taking over a lot of things that React _should_ have by default but doesn't. Which is fine, but Next.js is also a little too much for a lot of smaller projects I work on.
How is anyone supposed to get a job if they don't promote their own fiefdom?
I think we're at an interesting time for React routing. It seems like a ton of shops are standardizing on Next.js as a base for new projects, especially if you're building a pretty vanilla web app.
Since Next takes care of routing for you, the need for projects like this operating at huge scales is diminishing. I'm glad they still exist for teams that want/need to own the entire application stack, but there are benefits from the community standardizing too.
At my job (dev consulting agency), we're about to embark on rebuilding an in-house framework onto Next.js to take advantage of the larger community tooling and to simplify onboarding of new hires.
React Router has so far made it through 6 iterations, it wouldn't surprise me if v7 was some sort of drop-in plugin replacement within Next. It could open up some areas for more complex navigation requirements without some of the hacky workarounds you need in Next currently.
Interesting times indeed!
I'm not sure about that, Next.js' routing is very limited compared to React Router, so much so that I actually spent some time evaluating whether it was worth introducing react-router and skipping Next's half-arsed implementation of a router in a project at work.
I've been very vocal against Next multiple times recently, so I'm definitely biased, but I wouldn't use it for anything more than a basically static web app. Its whole API is very basic, and quite shallow and underdocumented when you need to go a little deeper than "compile this React component into a static html page" and filesystem-based routing.
Not that I'm a fan of React Router either, as they felt they needed to break their API contract five (!) times in a couple years of existence, but at least it presents some surface area and depth in its API if you need to build an slightly more complex app that's more than a static site.
Absolutely. Next’s router kind of kneecapped a feature we were building out recently and we had to adjust our implementation accordingly.
The router is so deeply entwined with getServerSideProps - we couldn’t find a way, including using shallow transitions, to push to the same path without triggering rebuilding the page due to a request to next/_data which returned the corresponding server side props.
Amongst other things. It’s a wonderful framework, there’s no question. The router is definitely not its strength though.
> Next.js' routing is very limited compared to React Router
What specifically do you find is lacking?
> I've been very vocal against Next multiple times recently, so I'm definitely biased, but I wouldn't use it for anything more than a basically static web app. Its whole API is very basic, and quite shallow and underdocumented when you need to go a little deeper than "compile this React component into a static html page" and filesystem-based routing.
Could you be more specific? Next.js was originally designed for server-rendered React apps, so I'm wondering how you landed to using it only for static web apps.
Especially would love to hear more about what you think is missing from the docs.
Wondering if Remix will be a good alternative for Next
Next's router is the only thing that holds me back from fully embracing it. It sucks that I have to give up every other awesome thing the framework offers when I have a project that does not fit with their router. Hoping something changed in the last year and someone can point me to a solution
I'm curious: what specific problems are you running into?
Nested routing. It's basically unusable for a master/detail view, which is common in dashboard apps.
Have you seen this? https://nextjs.org/docs/basic-features/layouts
So just use next with react-router?
Kinda defeats the purpose of NextJS's organization - the filesystem based routing is pretty key to their server side rendering logic and the cornerstone of their sensible defaults for making performant applications out of the box, vs just having a wildcard route that runs React Router - might as well just use CRA in that case, no?
> might as well just use CRA
Why would anyone use CRA when there is next? Either I write my webpack config, or I use a comercial tool with sensible default, and the flexibility to mix and match single page and SSR in the future.
There are many reasons, but what I was saying is that if you don't use the routing, then a lot of the value of NextJS disappears.
Could you share the reasons you don't pick Next.js? Are you only finding value in the file system routing?
I do pick NextJS, and I like it - but what I’m saying is the file system routing is critical to other features like static props and SSR, so if you don’t use the file system routing and try to work around it by using react router on some catch all wildcard route, I think you are missing out on a lot of the architectural perks of NextJS. For instance even with new features like edge middlewares, once again its behavior is dependent on using the file system routing.
Personally I actually don’t really like the file system routing, much preferring how route structure is expressed in code with react router (I had set up a system in another project to never have any broken links since page routes were enumerated in a type that links were forced to refer to by TypeScript; I just can’t do that with file system based routing without duplicating and needing to sync paths), but I feel like I’m obligated to use it by the virtue of having chosen NextJS and wanting to make use of its optimization features, so I’m just tolerating that.
Also hi leerob :)
I'm not sure you can, their router is how they handle data fetching for server-side rendering
What do you think will become of CRA, given next’s growth?
I still feel resentful about how earlier versions of react router had massive breaking changes effectively completely changing it, provided no documentation and no help at all even understanding the new thing let alone explaining how to upgrade.
To be fair I believe I once read they now don’t do that but it was truly scarring to naively update to the newest version thinking my app would need a few tweaks to get going again, when in fact big chunks needed rewriting, with zero help from the developers.
That's the definition of a major version change though...
A major version change may (or may not) have some breaking changes, but most good libraries have migration guides and documentation on how to upgrade. Presumably the parent comment was annoyed that the breaking changes also included no docs or guides.
Theoretically yes, but if you think of the metric of % of library-interacting lines of code an average library user needs to change to upgrade, React Router has been a huge outlier compared to other libraries in the React ecosystem. Your routing components would change completely. And the maintainers saw no problem with this.
False.
I really don't think react-router provides enough functionality to justify the amount of churn it's generating. URL routing is not complicated and not hard. After getting dragged through a v3->v4 upgrade by a library we use, I put in a lint rule forcing all usages of it to go through a wrapper.
I am I the only who finds this library a wee bit overengineered?
what part is over-engineered?
All of it.
Think of it this way. How would you do routing in a React app from scratch:
1. Listen for changes in the URL.
2. Parse the new URL into a routing object.
3. Pass the routing object down through the component hierarchy.
You can do that in maybe 5-10 lines of straightforward code.
The authors of React Router are developing a framework for React called remix[0]. It's not available yet, but it will be soon and it will be open source.
Remix will certainly use react-router and I expect it to be similar to NextJS but better. My expectation is Remix will blow NextJS out of the water and become the defacto starting point like how NextJS is today.
[0] remix.run
I was working on a project recently combining ViteJS and React Router to make a NextJS alternative. Mostly so that I have more control about where I host it and not so Lambda/Vercel optimised.
I don't really see how you could "blow NextJS out of the water" though. As a concept, NextJS nails it with the simple directory structure, api endpoints, a nice mix of server side and client side rendering. There's not much else I'd want from a web framework feature wise.
https://github.com/conradludgate/vite-react-ssr-next here's my project if anyone is interested. It kinda sucks at the moment though so definitely don't use it, but hopefully it might inspire someone
Is routing so hard you have to revamp it 6 times?