33 ms·

I normally try to keep comments here reasoned and civil but the amount of churn in this library is almost so much of a joke that it should become a meme. At thi

by n0us 10y ago

I normally try to keep comments here reasoned and civil but the amount of churn in this library is almost so much of a joke that it should become a meme. At this point it's almost more expensive for me to continue updating than it would be to just fork the library and maintain the upgrades myself. Any time I have to touch react-router I just resign the idea that I'm going to have to take at minimum a day to work out the bugs that pop up with every upgrade, (even minor changes). > Why the huge change? (AGAIN?!) > tl;dr Declarative Composability The huge change is because the maintainers are apparently unwilling or incapable of either A. Creating something good enough on the first, second, or third attempt, or B. are completely oblivious to the needs of devs trying to create practical software and don't understand that project stability is just as important as a good API. Thanks but no thanks.

kevan 10y ago
>At this point it's almost more expensive for me to continue updating than it would be to just fork the library and maintain the upgrades myself. I got burned by this in my last big project, we resigned ourselves to never upgrading past 1.0.0-beta4.
- n0us 10y ago
  There's a big difference between breaking changes which resolve real pain points in a language/framework/library, like the break between python 2 and 3 and changes that are just for the fun of it, because someone "felt like it was better". I like to view developing software as an investment. You are spending time and money outright, and there is an implicit cost in foregoing other opportunities when you make a technical choice. Investing in react-router is like investing in a clown. It's a total toss-up. The maintainers could all move on to whatever other hip lib and finally it will be stable, or you can continue betting large sums of money on what is basically a coin flip every 6 months: Are they going to screw with the library again (yes) and will it cause a bunch of bugs in my program (probably). It's a bad investment, esp if you try to upgrade. The ironic part of this is that honestly I feel like the V1 API is the best out of all of them. If they had just iterated and brought breaking changes that were actually needed instead of just those that they felt might be fun, the project would be much better for it in my opinion. (I know python <-> react-router comparison is apples to oranges but bear with me)
  - danabramov 10y ago
    I empathize with your frustration but please consider that changes in RR were not done "for fun". They were done to solve plenty of use cases that few (any?) routers in JS ecosystem ever had to deal with (universal rendering, avoiding waterfall of requests, animations). Solving each of these problem introduced some awkward APIs, but the community demanded them with a passion just like in this thread. We all built and learned. This rewrite is motivated by: (a) knowing the spectrum of use cases, (b) throwing out non-composable APIs that made it hard for everyone to extend the router, (c) eliminating a class of bugs caused by router trying to "orchestrate" everything instead of letting React do it. It was not obvious to the authors how to do it from day one. It was not obvious to me or anyone else. Everything is easy in hindsight ;-) It's sure rewarding to solve these problems for the authors, but this has nothing to do with "fun" and everything with creating something future users won't hate. All the churn in previous versions was caused by router fighting with React. Now it works together with React. Let's see how it pans out. And if you're pessimistic, keep using RR3, it's going to be maintained for a long time (you're not the only one using it ;-).
borplk 10y ago
I have to agree with that. The javascript ecosystem in general is extremely fragile. I have lost weeks and weeks worth of time investigating how X and Y silently broke again. And I say that as a hardcore webdev who is very well familiar with Javascript. Sometimes just makes me want to kiss it goodbye and go back to server or backend development for some sanity and stability.
- joshmanders 10y ago
  > I have lost weeks and weeks worth of time investigating how X and Y silently broke again. How does code just magically break on it's own? Either you did something wrong, or you're keeping details back. Code doesn't just work today and not tomorrow on it's own. Stop blaming others for your mistakes.
  - mullsork 10y ago
    My guess would be he/she did not lock the versions in package.json, but used "wildcards" (I consider `1.x` a wildcard.) Happened to me once, took about a day to figure out. I really dig `Gemfile.lock` in Ruby land for this purpose.
    - joshmanders 10y ago
      So I was correct in saying they did something wrong. :) npm follows semver and expects libraries to do the same, whether they do or not is up to the library author, but npm can't know if the library does or not. Therefor the user didn't pay attention to the library they are using and blindly installed it and set constraints that caused breaking changes to get into their code. Once again, not the ecosystems fault, but the developers fault.
      - kmudrick 10y ago
        Semver is wonderful... If every dependency in your dependency tree follows semver perfectly. But the reality is that while you may lock your immediate dependencies down, you are still at the mercy of what is probably a pretty deep tree of transitive dependencies, of which you have very little control over. Unless you resort to things like shrinkwrap in the npm world. Which kinda feels like a gigantic hack to me.
tbrock 10y ago
I'm with you. I'm so sick of this library. About the only thing they got right the first three times was the name of the package yet they have dragged everyone through countless iterations of regurgitated API churn to keep it instead of just creating a new one. Maintaining react-router and keeping up to date for a production site is a full time job I don't want. I realize I sound like the a whining open source leech but there is a huge opportunity for a stable library to emerge and capture mindshare here. Where is Facebook during all this? Someone needs to step up and solidify this critical react ecosystem component and it seems like it should be them. Obviously.
- acemarke 10y ago
  Per comments from the React devs, Facebook handles routing needs with their own internal stuff. They don't use anything like React-Router themselves, so they have no need to build or open-source something like that.
  - andrewingram 10y ago
    One thing worth adding is that along with Redux, React Router has been vocally blessed as the right solution by Facebook employees. This means it occupies an unusual position within the ecosystem in that it's a de-facto standard, and fairly critical to many projects. It definitely suffers from a documentation problem (the new examples are genuinely great, but previous versions were very light on practical examples and best practices).
    - acemarke 10y ago
      Thankfully, I've never had to deal with routing in any of the applications I've worked with. (Primarily internal stuff that is true "applications in a browser", rather than stuff addressable by sub-URLs.) So, I've managed to avoid all this complexity. Wasn't until relatively recently that I even understood what client-side routing actually involves. Personally, I think that routing in general is one of the major causes of "Javascript Fatigue", and is proof that building complex software is inherently complex. I will say that despite its "de-facto standard" nature, there's certainly a number of other options out there. I keep a list of Redux-related addons and utilities, and there's a couple dozen entries in the "Routing" category (https://github.com/markerikson/redux-ecosystem-links/blob/master/routing.md https://github.com/markerikson/redux-ecosystem-links/blob/ma...). Again, I haven't used any of them myself, but they exist. And that's _just_ "libs that relate to routing and Redux", much less "libs that relate to routing and React, or routing in general".
throwawaymsft 10y ago
Yep. I feel javascript library authors forget it's lines of code spent, not lines of code written. How would they feel about a contractor who had to rebuild their house 4 times? "Oh, they're really good about revving their design, this is great!"
- danabramov 10y ago
  Nope, library authors are trying to create a good product. When they fail, some of them try again. I'm an open source author myself, and comments like this make me think twice before sharing something. Maybe it's better I just keep that code to myself and not bother with the whole community thing. ;-)
- zuck9 10y ago
  I think a more apt analogy would be a public book library that gets rebuilt 4 times. On the 4th time though they built it alongside the old building instead of demolishing it.
szines 10y ago
You guys should switch to Ember, you never will have this problem and you get the best router ever. :)
- 0x142857 10y ago
  Maybe should switch to jQuery, then no router was required. lol
- DCoder 10y ago
  Yeah, instead of this problem Ember will give you other problems: https://www.google.com/search?q=site:https%3A%2F%2Fwhat.thedailywtf.com+ember https://www.google.com/search?q=site:https%3A%2F%2Fwhat.thed...
Finbarr 10y ago
I've been using react-router 0.13.4 for almost a year in a project and it works perfectly. I found no reason to upgrade and am now glad I didn't bother.
- enraged_camel 10y ago
  Same here. I don't understand why people always feel like they need to have the latest and greatest version, and then complain when shit breaks. How about this: if it ain't broke, don't upgrade.
  - joshmanders 10y ago
    No way, I can't do that! I'll get ridiculed for not being on the latest and greatest, and if I complain and take shots at the people building critical code for me to use for free, I'll get pats on the back by my peers!
    - DCoder 10y ago
      Magpie-Driven Development at its finest!
wpietri 10y ago
I was just talking with an acquaintance who's at a company that invested millions of developer-dollars in cutting-edge tech. 7-10 years later, after a long period of a few developers keeping everything together with duct tape, the whole thing is getting thrown out. Why? Well, some of it's solid code. That might be worth keeping. But some of it's technologies that fell out of fashion. And there's a bunch of stuff that people wrote in a frenzy, so there's a bunch of tech debt. And even if they stripped it down to the bones, there's a lot of upgrading to do just to get back to where they could do new work with modern libraries. From the business perspective it was easier just to glue together a bunch of outsourced services. I'm sure those developers all meant well by picking cutting-edge tech. But as Dan McKinley says, we should generally choose boring technology [1]. As you describe, the costs of keeping up with interesting things is substantial. On rare occasions, it's really worth paying that cost. But, mostly, as with my acquaintance's company, the costs can accumulate while your attention is elsewhere, pushing code bases into a sort of technical bankruptcy. [1] http://mcfunley.com/choose-boring-technology http://mcfunley.com/choose-boring-technology
- deegles 10y ago
  What would be the boring technology to pick for starting a web + backend project today?
  - n0us 10y ago
    python/ruby/java on backend. React/Ember/Angular on front end. The core libraries are relatively stable, it's mostly supporting libs that will burn you if you aren't careful.
  - wyager 10y ago
    Probably PHP and plain JS, which is why I think that argument doesn't make sense. New web stuff is currently so much better than the old alternative that dealing with tumultuous stability is often worth it.
    - tomca32 10y ago
cloudjacker 10y ago
and imagine my surprise when I found out Node 7 exists already sounds like hell!
ec109685 10y ago
In the large scheme of things, is a day that big of a cost to move to a newer routing approach?
bsimpson 10y ago
I know. I hate it when people learn stuff writing free libraries to support new technologies and then release upgrades informed by what they've learned. I've watched React Router grow from one-of-a-handful-of-experimental-routers-for-React-on-GitHub to the most well-known third-party library in the React ecosystem (tied with Redux). In that time, Michael and Ryan have learned plenty. They've also taught plenty. Libraries that experiment with their APIs, like React Router and React Motion, help all of us understand how to wield React better. I learned how to use contexts by dissecting React Router v0, when they were still an undocumented feature. I understand the frustration that upgrading creates. (My first React project was creating an isomorphic server - I was definitely sensitive to changes in the routing API.) Still, I hate seeing a whinefest every time a free library makes a change that an app author disagrees with. You're always welcome to {fork it, build/use something else, help maintain and give feedback on API direction}. Michael and Ryan are enormously friendly and welcoming to external input. Trying to embarrass the creators or turn them into some sort of open-source pariahs helps nobody.
- andy_ppp 10y ago
  If that were true why the pathological method renaming between versions. Maybe this is the equivalent of a 1.0 and now they are finally going to keep things stable but how can you trust that "this time".
  - bsimpson 10y ago
    If what was true?
- grovulent 10y ago
  One of the things I admire about the tech community is their willingness to just give away their code for free. This is a cultural fact that has underpinned such an enormous collective gain of everyone in the entire world that I get genuinely worried when I see people get that mad at open source maintainers. I look at the scientific community and their inability to share their data with one another out of paranoia, publishing incentives etc... it's not just bad for science, it's bad for their community - their ability to enjoy each other's company on a daily basis. So you know - I just feel you gotta be kind to open source maintainers. They didn't break anyone's app. They just released new code that you don't have to use.
antoaravinth 10y ago
I'm with you. First when I thought of building a SPA application with React on my side project; I tried React-Router, the API was not that easy to grasp at first for me. Then I have build my own router with `popstate` event and I'm quite happy with it. All the navigation history is pushed to redux. It turns out that it works really well for my needs and application.
- chrisabrams 10y ago
  Have a link to your router?
  - antoaravinth 10y ago
    Sorry, no. However, you can find the same pattern being used in the sound-redux project-https://github.com/andrewngu/sound-redux https://github.com/andrewngu/sound-redux
- wesleytodd 10y ago
  We did something similar that uses the Express router: https://github.com/wesleytodd/nighthawk https://github.com/wesleytodd/nighthawk The one thing we didn't do was layer on top of a flux solution. Seemed more future proof to not tie to anything other than a routing style. If you wanted to do that with our solution it would be as simple as writing an action to do the url change.
- tothepixel 10y ago
  I built a React app for a large Ecom site recently using the same strategy. It handles all URL updates with the History API, and simply AJAX loads the same URL with a query param to hydrate the app with JSON. Works really simply, and doesn't require Redux, Flux, or React Router.
jasim 10y ago
Routing stateful apps using string URLs is not a solved problem. Which thick-client app gives you a universally shareable string that restores it to a specific predictable state? How is it even possible? It took a confluence of web technologies, however ill-wrought, to make that possible today. No one has yet figured out a clean abstraction that solves this - yes it is hard to imagine that we still have new problems that were not solved in the 1960s by the Greats. This is not a computer science-y problem; it falls into the spectrum of craft and art than science. It'll be beautiful when it is framed correctly and an elegant solution comes out. From the looks of it, the authors of this library (along with the rest of the client-side router ecosystems) are the closest. The FAQ satisfactorily answers why they are trying this approach - React brought the concept of 'mounting' UI elements, and it applies equally well to routing as well. I do share the pain of having to keep up with a changing API; and it is especially biting when it feels gratuitous (which I think is not at all the case here), but let's chalk it up to the cost of being in the bleeding edge, working in one of the most well-paid professions in the world.
- ChrisCinelli 10y ago
  The only API that works well and give you all the flexibility is the one that the browser exposes. If you stick to something that is close to how the browser behaves, you should be fine. In the React ecosystem I have seen that people sometimes want to abstract too much with no real pragmatic advantages. The result is that the abstraction become verbose to use and get in the way for coding things that produce a better user experience. Things that used to be simple to build. Keep it simple. Make it more complex only when it is necessary.
  - jasim 10y ago
    All fair points, but we still have the problem of giving our users a URL to our rich web app which can take them into a node inside a nested state hierarchy. And not all applications can be purely server-side. You can't for example build a spreadsheet on the web as a series of request-responses.
- connorelsea 10y ago
acjohnson55 10y ago
> At this point it's almost more expensive for me to continue updating than it would be to just fork the library and maintain the upgrades myself. Ok...what's holding you up? I get the frustration, but if you like an older version you learned, just stay with it and maintain it yourself. Or do your own thing completely with another routing solution. Or roll up your sleeves and write your own. Maybe in a year, if the new version still looks like the way to go, put in the effort to switch over. You have a multitude of options. People act like the authors of the library are intentionally toying with them. And this is for something that presumably no one has paid for! The sense of entitlement that erupts every time some non-contiguous jump in progress happens is the far worse meme, to me.
- Klathmon 10y ago
  Also, they will be supporting the v3 version of the code "indefinitely". So it's not like he/she would even need to fork the project to continue to support the old version...
wesleytodd 10y ago
This is one of the major reasons I try to stick with more well established libraries when I can. For example, when choosing our teams universal routing solution, I used the Express router instead of going with the NEW SHINY react router. Of course this did mean wrapping it for use on the FE, but that was as easy as copying code form Page.js (another old school project). https://github.com/wesleytodd/nighthawk https://github.com/wesleytodd/nighthawk
dham 10y ago
React Router and the problems dealing with minor updates was one of the several libraries(around 6) that sparked me to write the Sad State of Web Development
STRML 10y ago
If you're sick of the churn, I've been maintaining Andrey Popp's original React-Router-Component [1] for the last few years. It's a simple router that hasn't changed much. I've tried to keep it extensible and simple. 1. https://github.com/STRML/react-router-component https://github.com/STRML/react-router-component
coldtea 10y ago
>The huge change is because the maintainers are apparently unwilling or incapable of either A. Creating something good enough on the first, second, or third attempt Well, it was "good enough" to be the #1 used solution and be adopted by almost everybody in the ecosystem, even if it wasn't "perfectly nailed" the first, second, or even third time. So, there's that. If there are some better developers out there that can do it better and with less churn, where are they, and where's their project? >B. are completely oblivious to the needs of devs trying to create practical software and don't understand that project stability is just as important as a good API. Well, given the rate of churn in the NPM world, they aren't unlike anybody else...
agnivade 10y ago
Do you have a better suggestion for a routing library at the moment ?

by n0us 10y ago

kevan 10y ago

>At this point it's almost more expensive for me to continue updating than it would be to just fork the library and maintain the upgrades myself. I got burned by this in my last big project, we resigned ourselves to never upgrading past 1.0.0-beta4.

n0us 10y ago
There's a big difference between breaking changes which resolve real pain points in a language/framework/library, like the break between python 2 and 3 and changes that are just for the fun of it, because someone "felt like it was better". I like to view developing software as an investment. You are spending time and money outright, and there is an implicit cost in foregoing other opportunities when you make a technical choice. Investing in react-router is like investing in a clown. It's a total toss-up. The maintainers could all move on to whatever other hip lib and finally it will be stable, or you can continue betting large sums of money on what is basically a coin flip every 6 months: Are they going to screw with the library again (yes) and will it cause a bunch of bugs in my program (probably). It's a bad investment, esp if you try to upgrade. The ironic part of this is that honestly I feel like the V1 API is the best out of all of them. If they had just iterated and brought breaking changes that were actually needed instead of just those that they felt might be fun, the project would be much better for it in my opinion. (I know python <-> react-router comparison is apples to oranges but bear with me)
- danabramov 10y ago
  I empathize with your frustration but please consider that changes in RR were not done "for fun". They were done to solve plenty of use cases that few (any?) routers in JS ecosystem ever had to deal with (universal rendering, avoiding waterfall of requests, animations). Solving each of these problem introduced some awkward APIs, but the community demanded them with a passion just like in this thread. We all built and learned. This rewrite is motivated by: (a) knowing the spectrum of use cases, (b) throwing out non-composable APIs that made it hard for everyone to extend the router, (c) eliminating a class of bugs caused by router trying to "orchestrate" everything instead of letting React do it. It was not obvious to the authors how to do it from day one. It was not obvious to me or anyone else. Everything is easy in hindsight ;-) It's sure rewarding to solve these problems for the authors, but this has nothing to do with "fun" and everything with creating something future users won't hate. All the churn in previous versions was caused by router fighting with React. Now it works together with React. Let's see how it pans out. And if you're pessimistic, keep using RR3, it's going to be maintained for a long time (you're not the only one using it ;-).

borplk 10y ago

I have to agree with that. The javascript ecosystem in general is extremely fragile. I have lost weeks and weeks worth of time investigating how X and Y silently broke again. And I say that as a hardcore webdev who is very well familiar with Javascript. Sometimes just makes me want to kiss it goodbye and go back to server or backend development for some sanity and stability.

joshmanders 10y ago
> I have lost weeks and weeks worth of time investigating how X and Y silently broke again. How does code just magically break on it's own? Either you did something wrong, or you're keeping details back. Code doesn't just work today and not tomorrow on it's own. Stop blaming others for your mistakes.
- mullsork 10y ago
  My guess would be he/she did not lock the versions in package.json, but used "wildcards" (I consider `1.x` a wildcard.) Happened to me once, took about a day to figure out. I really dig `Gemfile.lock` in Ruby land for this purpose.
  - joshmanders 10y ago
    So I was correct in saying they did something wrong. :) npm follows semver and expects libraries to do the same, whether they do or not is up to the library author, but npm can't know if the library does or not. Therefor the user didn't pay attention to the library they are using and blindly installed it and set constraints that caused breaking changes to get into their code. Once again, not the ecosystems fault, but the developers fault.
    - kmudrick 10y ago
      Semver is wonderful... If every dependency in your dependency tree follows semver perfectly. But the reality is that while you may lock your immediate dependencies down, you are still at the mercy of what is probably a pretty deep tree of transitive dependencies, of which you have very little control over. Unless you resort to things like shrinkwrap in the npm world. Which kinda feels like a gigantic hack to me.

tbrock 10y ago

I'm with you. I'm so sick of this library. About the only thing they got right the first three times was the name of the package yet they have dragged everyone through countless iterations of regurgitated API churn to keep it instead of just creating a new one. Maintaining react-router and keeping up to date for a production site is a full time job I don't want. I realize I sound like the a whining open source leech but there is a huge opportunity for a stable library to emerge and capture mindshare here. Where is Facebook during all this? Someone needs to step up and solidify this critical react ecosystem component and it seems like it should be them. Obviously.

acemarke 10y ago
Per comments from the React devs, Facebook handles routing needs with their own internal stuff. They don't use anything like React-Router themselves, so they have no need to build or open-source something like that.
- andrewingram 10y ago
  One thing worth adding is that along with Redux, React Router has been vocally blessed as the right solution by Facebook employees. This means it occupies an unusual position within the ecosystem in that it's a de-facto standard, and fairly critical to many projects. It definitely suffers from a documentation problem (the new examples are genuinely great, but previous versions were very light on practical examples and best practices).
  - acemarke 10y ago
    Thankfully, I've never had to deal with routing in any of the applications I've worked with. (Primarily internal stuff that is true "applications in a browser", rather than stuff addressable by sub-URLs.) So, I've managed to avoid all this complexity. Wasn't until relatively recently that I even understood what client-side routing actually involves. Personally, I think that routing in general is one of the major causes of "Javascript Fatigue", and is proof that building complex software is inherently complex. I will say that despite its "de-facto standard" nature, there's certainly a number of other options out there. I keep a list of Redux-related addons and utilities, and there's a couple dozen entries in the "Routing" category (https://github.com/markerikson/redux-ecosystem-links/blob/master/routing.md https://github.com/markerikson/redux-ecosystem-links/blob/ma...). Again, I haven't used any of them myself, but they exist. And that's _just_ "libs that relate to routing and Redux", much less "libs that relate to routing and React, or routing in general".

throwawaymsft 10y ago

Yep. I feel javascript library authors forget it's lines of code spent, not lines of code written. How would they feel about a contractor who had to rebuild their house 4 times? "Oh, they're really good about revving their design, this is great!"

danabramov 10y ago
Nope, library authors are trying to create a good product. When they fail, some of them try again. I'm an open source author myself, and comments like this make me think twice before sharing something. Maybe it's better I just keep that code to myself and not bother with the whole community thing. ;-)
zuck9 10y ago
I think a more apt analogy would be a public book library that gets rebuilt 4 times. On the 4th time though they built it alongside the old building instead of demolishing it.

szines 10y ago

You guys should switch to Ember, you never will have this problem and you get the best router ever. :)

0x142857 10y ago
Maybe should switch to jQuery, then no router was required. lol
DCoder 10y ago
Yeah, instead of this problem Ember will give you other problems: https://www.google.com/search?q=site:https%3A%2F%2Fwhat.thedailywtf.com+ember https://www.google.com/search?q=site:https%3A%2F%2Fwhat.thed...

Finbarr 10y ago

I've been using react-router 0.13.4 for almost a year in a project and it works perfectly. I found no reason to upgrade and am now glad I didn't bother.

enraged_camel 10y ago
Same here. I don't understand why people always feel like they need to have the latest and greatest version, and then complain when shit breaks. How about this: if it ain't broke, don't upgrade.
- joshmanders 10y ago
  No way, I can't do that! I'll get ridiculed for not being on the latest and greatest, and if I complain and take shots at the people building critical code for me to use for free, I'll get pats on the back by my peers!
  - DCoder 10y ago
    Magpie-Driven Development at its finest!

wpietri 10y ago

I was just talking with an acquaintance who's at a company that invested millions of developer-dollars in cutting-edge tech. 7-10 years later, after a long period of a few developers keeping everything together with duct tape, the whole thing is getting thrown out. Why? Well, some of it's solid code. That might be worth keeping. But some of it's technologies that fell out of fashion. And there's a bunch of stuff that people wrote in a frenzy, so there's a bunch of tech debt. And even if they stripped it down to the bones, there's a lot of upgrading to do just to get back to where they could do new work with modern libraries. From the business perspective it was easier just to glue together a bunch of outsourced services. I'm sure those developers all meant well by picking cutting-edge tech. But as Dan McKinley says, we should generally choose boring technology [1]. As you describe, the costs of keeping up with interesting things is substantial. On rare occasions, it's really worth paying that cost. But, mostly, as with my acquaintance's company, the costs can accumulate while your attention is elsewhere, pushing code bases into a sort of technical bankruptcy. [1] http://mcfunley.com/choose-boring-technology http://mcfunley.com/choose-boring-technology

deegles 10y ago
What would be the boring technology to pick for starting a web + backend project today?
- n0us 10y ago
  python/ruby/java on backend. React/Ember/Angular on front end. The core libraries are relatively stable, it's mostly supporting libs that will burn you if you aren't careful.
- wyager 10y ago
  Probably PHP and plain JS, which is why I think that argument doesn't make sense. New web stuff is currently so much better than the old alternative that dealing with tumultuous stability is often worth it.
  - tomca32 10y ago

cloudjacker 10y ago

and imagine my surprise when I found out Node 7 exists already sounds like hell!

ec109685 10y ago

In the large scheme of things, is a day that big of a cost to move to a newer routing approach?

bsimpson 10y ago

I know. I hate it when people learn stuff writing free libraries to support new technologies and then release upgrades informed by what they've learned. I've watched React Router grow from one-of-a-handful-of-experimental-routers-for-React-on-GitHub to the most well-known third-party library in the React ecosystem (tied with Redux). In that time, Michael and Ryan have learned plenty. They've also taught plenty. Libraries that experiment with their APIs, like React Router and React Motion, help all of us understand how to wield React better. I learned how to use contexts by dissecting React Router v0, when they were still an undocumented feature. I understand the frustration that upgrading creates. (My first React project was creating an isomorphic server - I was definitely sensitive to changes in the routing API.) Still, I hate seeing a whinefest every time a free library makes a change that an app author disagrees with. You're always welcome to {fork it, build/use something else, help maintain and give feedback on API direction}. Michael and Ryan are enormously friendly and welcoming to external input. Trying to embarrass the creators or turn them into some sort of open-source pariahs helps nobody.

andy_ppp 10y ago
If that were true why the pathological method renaming between versions. Maybe this is the equivalent of a 1.0 and now they are finally going to keep things stable but how can you trust that "this time".
- bsimpson 10y ago
  If what was true?
grovulent 10y ago
One of the things I admire about the tech community is their willingness to just give away their code for free. This is a cultural fact that has underpinned such an enormous collective gain of everyone in the entire world that I get genuinely worried when I see people get that mad at open source maintainers. I look at the scientific community and their inability to share their data with one another out of paranoia, publishing incentives etc... it's not just bad for science, it's bad for their community - their ability to enjoy each other's company on a daily basis. So you know - I just feel you gotta be kind to open source maintainers. They didn't break anyone's app. They just released new code that you don't have to use.

antoaravinth 10y ago

I'm with you. First when I thought of building a SPA application with React on my side project; I tried React-Router, the API was not that easy to grasp at first for me. Then I have build my own router with `popstate` event and I'm quite happy with it. All the navigation history is pushed to redux. It turns out that it works really well for my needs and application.

chrisabrams 10y ago
Have a link to your router?
- antoaravinth 10y ago
  Sorry, no. However, you can find the same pattern being used in the sound-redux project-https://github.com/andrewngu/sound-redux https://github.com/andrewngu/sound-redux
wesleytodd 10y ago
We did something similar that uses the Express router: https://github.com/wesleytodd/nighthawk https://github.com/wesleytodd/nighthawk The one thing we didn't do was layer on top of a flux solution. Seemed more future proof to not tie to anything other than a routing style. If you wanted to do that with our solution it would be as simple as writing an action to do the url change.
tothepixel 10y ago
I built a React app for a large Ecom site recently using the same strategy. It handles all URL updates with the History API, and simply AJAX loads the same URL with a query param to hydrate the app with JSON. Works really simply, and doesn't require Redux, Flux, or React Router.

jasim 10y ago

Routing stateful apps using string URLs is not a solved problem. Which thick-client app gives you a universally shareable string that restores it to a specific predictable state? How is it even possible? It took a confluence of web technologies, however ill-wrought, to make that possible today. No one has yet figured out a clean abstraction that solves this - yes it is hard to imagine that we still have new problems that were not solved in the 1960s by the Greats. This is not a computer science-y problem; it falls into the spectrum of craft and art than science. It'll be beautiful when it is framed correctly and an elegant solution comes out. From the looks of it, the authors of this library (along with the rest of the client-side router ecosystems) are the closest. The FAQ satisfactorily answers why they are trying this approach - React brought the concept of 'mounting' UI elements, and it applies equally well to routing as well. I do share the pain of having to keep up with a changing API; and it is especially biting when it feels gratuitous (which I think is not at all the case here), but let's chalk it up to the cost of being in the bleeding edge, working in one of the most well-paid professions in the world.

ChrisCinelli 10y ago
The only API that works well and give you all the flexibility is the one that the browser exposes. If you stick to something that is close to how the browser behaves, you should be fine. In the React ecosystem I have seen that people sometimes want to abstract too much with no real pragmatic advantages. The result is that the abstraction become verbose to use and get in the way for coding things that produce a better user experience. Things that used to be simple to build. Keep it simple. Make it more complex only when it is necessary.
- jasim 10y ago
  All fair points, but we still have the problem of giving our users a URL to our rich web app which can take them into a node inside a nested state hierarchy. And not all applications can be purely server-side. You can't for example build a spreadsheet on the web as a series of request-responses.
connorelsea 10y ago

acjohnson55 10y ago

> At this point it's almost more expensive for me to continue updating than it would be to just fork the library and maintain the upgrades myself. Ok...what's holding you up? I get the frustration, but if you like an older version you learned, just stay with it and maintain it yourself. Or do your own thing completely with another routing solution. Or roll up your sleeves and write your own. Maybe in a year, if the new version still looks like the way to go, put in the effort to switch over. You have a multitude of options. People act like the authors of the library are intentionally toying with them. And this is for something that presumably no one has paid for! The sense of entitlement that erupts every time some non-contiguous jump in progress happens is the far worse meme, to me.

Klathmon 10y ago
Also, they will be supporting the v3 version of the code "indefinitely". So it's not like he/she would even need to fork the project to continue to support the old version...

wesleytodd 10y ago

This is one of the major reasons I try to stick with more well established libraries when I can. For example, when choosing our teams universal routing solution, I used the Express router instead of going with the NEW SHINY react router. Of course this did mean wrapping it for use on the FE, but that was as easy as copying code form Page.js (another old school project). https://github.com/wesleytodd/nighthawk https://github.com/wesleytodd/nighthawk

dham 10y ago

React Router and the problems dealing with minor updates was one of the several libraries(around 6) that sparked me to write the Sad State of Web Development

STRML 10y ago

If you're sick of the churn, I've been maintaining Andrey Popp's original React-Router-Component [1] for the last few years. It's a simple router that hasn't changed much. I've tried to keep it extensible and simple. 1. https://github.com/STRML/react-router-component https://github.com/STRML/react-router-component

coldtea 10y ago

>The huge change is because the maintainers are apparently unwilling or incapable of either A. Creating something good enough on the first, second, or third attempt Well, it was "good enough" to be the #1 used solution and be adopted by almost everybody in the ecosystem, even if it wasn't "perfectly nailed" the first, second, or even third time. So, there's that. If there are some better developers out there that can do it better and with less churn, where are they, and where's their project? >B. are completely oblivious to the needs of devs trying to create practical software and don't understand that project stability is just as important as a good API. Well, given the rate of churn in the NPM world, they aren't unlike anybody else...

agnivade 10y ago

Do you have a better suggestion for a routing library at the moment ?