Clarifications regarding React Router's long-term vision #10496
Replies: 2 comments
-
Totally agree! Would be great to have some clarifications over the points above to better understand how to implement react-router in the best way. |
Beta Was this translation helpful? Give feedback.
-
Thanks for the question! It's a good one. The tl;dr is in your message already 😅
Yep! That's why the docs say:
We'll keep supporting that for the foreseeable future. And for a bit more explanation, please continue 😁
I don't think opinionated is the right word, but there are tradeoffs: things that make data loading more efficient work against things like "background location for modals". But you are right, there are some use cases that are solved well with the I'd like to clarify something from this comment a bit:
Remix is based on the principles of React Router, not the other way around. Remix is a just a server and bundler for React Router. In fact, v4/5 is the only version of React Router that didn't have some sort of data features. The original We added the new data features to Remix first because we weren't sure where the server, bundler, and router integration points were, so we just did it all where the bundler and server were. In an alternative timeline, I would have preferred to have done it in React Router first (the way new features are developed today) but it's difficult to know the end from the beginning. In summary: you don't have to use every feature of React Router and we'll continue supporting matching components to URLs in the middle of the component tree for the foreseeable future. You can even mix and match. Use a I hope this helps. Thanks for asking 🤘 (if you have any follow up questions, please let us know) |
Beta Was this translation helpful? Give feedback.
-
Hello everyone, just wanted to understand better your long-term vision before making any decision on big projects.
Under Picking a Router, it can be read:
But right after that, under Web Projects, there is:
So, the motives of your recommendation are not fully clear:
The later point is the one that worries me the most, especially if the true answer is a combination of the others too.
Probably because of how the documentation is written, or just because everyone likes to be up-to-date, people is trying really hard to migrate or to start new implementations using the new routers. The problem is that, despite some notorious benefits, the new routers seem to be a lot more opinionated than the old ones, almost forbidding any pattern that is slightly different from the proposed ones. They also include a lot of stuff that some people might consider "extras".
Just scratching the surface of the discussions I could find some perplexity that can be related to this:
Don't get me wrong, Remix is really nice, but maybe not everyone wants to use it, it is one good pattern in a sea of other good ones, and sometimes the overhead is not acceptable.
Maybe all of this is just a misunderstanding and it can be solved by modifying the documentation to clearly say: "Hey, you are free to use any of these routers based on your needs. Some of them focus on navigation only, while others add some Remix-style sugar, if that is your thing. All routers are stable, perform similarly and will be equally maintained in the foreseeable future."
React Router is a major open source project, with almost 10 million downloads per week on NPM. It is safe to assume that the great majority of React apps out there are using some version of React Router. Please, be careful, because navigation is a core functionality and should be one of the less opinionated ones.
I am sure there are awesome features, patterns and ideas out there and it is great to make them widely available, but everything that is a plus, beyond classic navigation, should be opt-in, IMHO.
Beta Was this translation helpful? Give feedback.
All reactions