You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is the React Router team planning ever to settle on a paradigm for defining a route configuration? It seems like around once a year or so, the paradigm completely changes. In v4, you had <Router> and <Route> components. In v6, you completely changed things up to use <RouterProvider> and functions like createBrowserRouter() for creating data routers. Now in v7, you completely changed things again to the new route module framework. Change has been a fairly constant feature of React Router.
I understand that all the old ways of doing things are more or less supported in v7, and I can stick with my <RouterProvider> if I want to. However, there's pressure on developers to constantly adopt the new paradigm because:
Documentation is maintained for the new paradigm, not so much for the old paradigm, so it becomes harder to learn how to make updates to your router configuration when you're still working within the old paradigm.
Features and fixes are implemented mainly for the latest version. I could just keep "react-router-dom": "^6.28.0" in my package.json, but eventually I'd fall behind, potentially missing fixes for vulnerabilities, major bugs, etc.
For developers, frequently needing to update application code to reflect a new routing paradigm takes a lot of work! I spent many hours updating my projects from the v4 paradigm to the v6 paradigm. Now, apparently, I'll need at some point to spend a bunch of hours updating my projects to the v7 paradigm. My projects are relatively small, and I hate to imagine how much work was/will be involved in updating larger projects. These are developer hours that are more or less wasted, not spent on improving the application's functionality, adding features, or fixing bugs, but rather just spinning the wheels to keep up with a changing dependency while the application itself stands still.
I'd implore the React Router team to keep these developer hours in mind (along with the poor developers spending them) next time you're considering upending the current paradigm implemented by React Router. Stability is an important aspect of software quality that seems not highly valued within much of the React community, and to me, React Router is one of the worst culprits when it comes to maintaining an unstable piece of software (where by "unstable" I mean constantly changing from the user's perspective). That instability comes with a cost that is borne mostly by other developers, and it doesn't always feel to me like that cost is weighed against whatever benefits are offered by the newer paradigms.
A project like Express (itself a routing framework) is a great example of one with a dead stable API. It hasn't really changed for more than a decade. Still, Express continues to be one of the most downloaded packages on NPM, likely in large part due to its stability. Could the React Router team strive for something close to that level of stability?
I'm sorry for the rant. I'm personally frustrated by the need to constantly keep up with React Router. I'd rather spend my limited development time doing fun things with my apps instead of slogging away refactoring code and updating the routing configuration. I'm curious how many other React Router users feel the same way and would favor greater stability.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Is the React Router team planning ever to settle on a paradigm for defining a route configuration? It seems like around once a year or so, the paradigm completely changes. In v4, you had
<Router>
and<Route>
components. In v6, you completely changed things up to use<RouterProvider>
and functions likecreateBrowserRouter()
for creating data routers. Now in v7, you completely changed things again to the new route module framework. Change has been a fairly constant feature of React Router.I understand that all the old ways of doing things are more or less supported in v7, and I can stick with my
<RouterProvider>
if I want to. However, there's pressure on developers to constantly adopt the new paradigm because:"react-router-dom": "^6.28.0"
in mypackage.json
, but eventually I'd fall behind, potentially missing fixes for vulnerabilities, major bugs, etc.For developers, frequently needing to update application code to reflect a new routing paradigm takes a lot of work! I spent many hours updating my projects from the v4 paradigm to the v6 paradigm. Now, apparently, I'll need at some point to spend a bunch of hours updating my projects to the v7 paradigm. My projects are relatively small, and I hate to imagine how much work was/will be involved in updating larger projects. These are developer hours that are more or less wasted, not spent on improving the application's functionality, adding features, or fixing bugs, but rather just spinning the wheels to keep up with a changing dependency while the application itself stands still.
I'd implore the React Router team to keep these developer hours in mind (along with the poor developers spending them) next time you're considering upending the current paradigm implemented by React Router. Stability is an important aspect of software quality that seems not highly valued within much of the React community, and to me, React Router is one of the worst culprits when it comes to maintaining an unstable piece of software (where by "unstable" I mean constantly changing from the user's perspective). That instability comes with a cost that is borne mostly by other developers, and it doesn't always feel to me like that cost is weighed against whatever benefits are offered by the newer paradigms.
A project like Express (itself a routing framework) is a great example of one with a dead stable API. It hasn't really changed for more than a decade. Still, Express continues to be one of the most downloaded packages on NPM, likely in large part due to its stability. Could the React Router team strive for something close to that level of stability?
I'm sorry for the rant. I'm personally frustrated by the need to constantly keep up with React Router. I'd rather spend my limited development time doing fun things with my apps instead of slogging away refactoring code and updating the routing configuration. I'm curious how many other React Router users feel the same way and would favor greater stability.
Beta Was this translation helpful? Give feedback.
All reactions