RRTR?

[BerkeleyTrue]

Why the move to RRTR from react-router? There isn't any explanation as to why and what rrtr.

[taion]

Sorry, I'll have a post up shortly.

[taion]

rrtr is my new, actively maintained fork of React Router. See https://medium.com/@taion/react-router-is-dead-long-live-rrtr-d229ca30e318.

The maintenance situation with React Router is extremely bad right now. As it stands, I don't see a way forward to get the functionality I and others need from a routing framework from React Router, as the project is currently managed.

[BerkeleyTrue]

Thanks for the explanation. Seems like a better solution would have been to fork this project and rename it instead, considering this no longer uses React Router and this project is called React-Router-Bootstrap.

I'll need to look into RRTR (What does that stand for anyways?) as there are a lot of things lacking (SSR stuff) from RR that I need. I've always chopped it up to the team behind RR being more front-end oriented.

[jquense]

RRTR is a fork of React-router so it has the same features.

[BerkeleyTrue]

@jquense It may have the same features, but those using this project currently expect it to use RR.

[taion]

rrtr is just "React Router" with a lot of vowels taken out. At the moment, it's almost just a straight fork of React Router. I made the fork so that I'll have the ability to maintain it actively going forward and start building out extra features that I'll need.

In an ideal world, maybe it will be possible to unfork the router down the road, but for now this is the only way forward that I could fine.

Would you care to drop an issue on rrtr regarding what's missing in terms of SSR support? I'd love to expand that part of the feature set if possible.

[BerkeleyTrue]

@taion Sure, and to be clear I'm not saying this is or isn't the right move.

Now that this project uses another router, albeit it is a fork it still is another router under another package name, I now need to peg my projects deps to the last version.

I cannot just move over to another router package as your packages are not the only packages I use that depend on RR. As such, moving to RRTR is not a drop in replacement, but a lot of work that would involve me forking other projects so the peer dependencies all line up.

And if I peg my dep to this project I have to deal with greenkeeper opening up a PR every time you release a new version of this package. Not a big hassle but a hassle nonetheless.

So my options are to either peg RR-bootstrap and deal with the annoyance or fork this project, revert back to the last RR version, and release my own RR-bootstrap to npm.

[taion]

Yeah, the package management is a pain. I'm really sorry about that. I felt like ultimately it'd be the best to keep these legacy projects under their current names to offer the best upgrade path (i.e. only swap out react-router).

I spent a massive chunk of this morning cutting these libraries over. It's a pain. I'm sorry.

[brendan-hurley]

@taion - Thanks for making this - I've used this a bunch of times. I was a little confused by this (it took looking through commits to find myself here!). Maybe put a little note in the readme files, with a link to your article?

[brendan-hurley]

I'd be happy to help out on rrtr if the case is that react-router is falling beind. During a 6 month project the whole underlying API changed about 2-3 times with that package - so I appreciate the move towards a more stable api.

[taion]

That's the problem, pretty much.

rrtr is going to see some API change, but the API changes will be incremental. It really doesn't make sense to completely change the API of a project that's as broadly used as React Router in big bang major releases that require app rewrites.

That's not particularly useful to anyone.

[BerkeleyTrue]

ultimately it'd be the best to keep these legacy projects under their current names to offer the best upgrade path

@taion This is a huge assumption, one that should have been an issue with a conversation instead.

So what is the solution?

[taion]

I don't know. I'm trying to do my best here.

Which libraries do you need?

[brendan-hurley]

How about tracking a @next release in npm where the peer dependency is rrtr?

[BerkeleyTrue]

@taion There is no anger or malice in my voice, but I do think there are certain rules that need to be followed in order to ensure a stable ecosystem.

Other than this one project? I'm using react-router-redux.

The best solution would be to re-release this project reverting back to RR and release a version of this project under another name that uses RRTR. If you no longer plan to maintain this project (the one using react-router), than I'd ask to see if you can find someone else wiling to maintain it and transfer the ownership to them.

I'm interested in seeing how RRTR does stack up to RR now and in the future, but It's not fair to assume all your users are willing and able to convert to RRTR right away.

[taion]

I think ultimately it's a judgment call. I do feel like it's my responsibility as a maintainer to point users at a package that will be kept up-to-date. I appreciate your concern that the naming is not ideal, but I really do feel like this offers the most seamless transition.

Would it help if I were to maintain a fork of react-router-redux as well?

[BerkeleyTrue]

but I really do feel like this offers the most seamless transition.

Again this makes the assumption that your users are willing and able, which I am not. it's unfortunate that you've come to this decision, but in the end this is your project and you can do with it as you please, even if it is at the expense of the community.

I do want to thank you and the others who have worked on this project to fill in the gap between RR and React-Bootstap.

[taion]

I think this is the least bad way to go. This isn't settled, and it's close, but I ultimately don't want to strand users on e.g. react-router-bootstrap with something that I feel to be a subpar solution.

I did push this as a major version bump on purpose – it is such; but I don't think it's more than such.

[taion]

Re-opening for discussion. I agree that this situation is confusing and not ideal. Give me a bit to think about what to do.

[mtscout6]

I think in the spirit of doing the least amount of harm possible to end users it would stand to reason that this should still be dependent on React-Router. The end users of this took on it on because they are using React-Bootstrap and React-Router and wanted a better way to bridge the two.

I understand your need for a different router that can be changed at a different rate than React-Router. Though that's a decision that you needed to make for yourself that you cannot impose on those using this library. These end users have their own reasons for using React-Router over other solutions.

I would argue that the best course of action would be to fork this and start a new project with a new name. You can publicly announce that you will not be maintaining this project anymore and make a call to the community to hand it off to someone that's using it. If no one accepts your challenge to pick up the torch than so be it, it will be a dead project. A new torch bearer may come along today, it may be a few months from now; but at least it does the least amount of harm to those currently using it.

[taion]

Fine. I'll revert my PR and unpublish v0.21.0.

[taion]

Wait, no, that's going to break a bunch of my code. Give me a sec.

[taion]

Okay, so I think the best way to go is to publish a v0.22.0 here that moves the dependency back to React Router, then spin up an extra rrtr-bootstrap. I'll need to find some time to do this.

[taion]

Released as v0.22.0.