React Router 6(reactrouter.com) |
React Router 6(reactrouter.com) |
The v5 -> v6 doc is already making me dizzy just from how long it is https://reactrouter.com/docs/en/v6/upgrading/v5
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'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/
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.
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.
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!
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.
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.
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 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.
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.
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.
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.
Sold.
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.
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 :)