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.
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.
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.
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>();
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.
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.
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.
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
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?
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.
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.
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.
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.
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.
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.