
React Router v4 FAQ - clessg
https://github.com/ReactTraining/react-router/blob/v4/README.md
======
n0us
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.

~~~
bsimpson
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.

~~~
n0us
> 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

> Libraries that experiment with their APIs, like React Router and React
> Motion, help all of us understand how to wield React better

If I read this correctly, you believe that it is still in experimental phase?
I don't have any problem with people learning and experimenting, but using
major release versions a your petri dish is obnoxious for all the thousands of
people using react-router even if it is convenient for the core maintainers.
There is a difference between an upgrade and an overhaul, with the extent of
the changes over V2,3,4 they might as well have just released a completely new
routing library or just maintained an experimental branch to figure out what
actually works before releasing a series of major breaking changes in quick
succession to the greater world. I'm aware that breaking changes are necessary
sometimes, but rapid churn is not necessary, esp once you are post 1.0
release. If there were some burning reason to release an upgrade then that
would make sense but this release does not even address some of my major pain
points with the API.

I also am not complaining about the cost and personally I don't see any
validity in the "it's free so I am beyond reproach" mentality that open source
people seem to have. What makes you think that I would thank someone for
something that was free even if I didn't want it? Or that anyone would for
that matter. Thanking people regardless of what they did, just because they
did it for free, is one way to erase market signals which govern the direction
of open source projects. I would rather just be candid and honest so that
maybe people will remember that me and other devs in general are negatively
impacted by breaking changes and therefore will consider keeping projects
stable.

I also didn't "try to embarrass the creators" and the only person on here to
made this personal was you, who decided to name the maintainers by first name.

~~~
felipellrocha
> personally I don't see any validity in the "it's free so I am beyond
> reproach" mentality that open source people seem to have. What makes you
> think that I would thank someone for something that was free even if I
> didn't want it? Or that anyone would for that matter. Thanking people
> regardless of what they did, just because they did it for free, is one way
> to erase market signals which govern the direction of open source projects.

Damn. Most of the time people follow their reasoning with, "I am paying for
this, so do the stuff I want exactly how I want." But, This is the first time
I've seen someone using the free-market to excuse being a dick to someone
who's giving their work out to the world for free. The amount of entitlement
mentality in this person is so unreal, I'm literally almost exploding in rage
here, because I can't believe anyone would treat anyone else like that.

To the maintainers: 99.999% of people out there are not like this person, and
we appreciate your work very much. Thanks for putting that work out there.
Your effort is also unreal, but a kind version of unreal!

------
kfinley
Interesting change. If I understand correctly, basically you have a base
component that updates fragments of the UI based on the route.

    
    
        const App = () => (
          <BrowserRouter>
            <h1>Hello World</h1>
            <Match exactly pattern="/" component={Home} />
            <Match pattern="/about" component={About} />
            <Miss component={NoMatch}/>
          </BrowserRouter>
        )
    

Couldn't we take it one step farther and just use a switch statement? It seems
like using pure JavaScript would be more idiomatic React. The URL pattern
could be parsed in the data layer, and passed down as props. That way the
components don't rely on global state, making them easier to test.

    
    
        const App = (screen, args) => {
          let content;
          switch (screen) {
          case 'home':
            content = <Home args={args} />
            break;
          case 'about':
            content = <About args={args} />
            break;
          default:
            content = <NoMatch args={args} />
            break;
          }
          return (
            <div>
              <h1>Hello World</h1>
              {content}
            </div>
          )
        }
    

It's probably just a matter of preference. Recently I started using React-
Storybook, so I've become addicted to "dumb" components.

~~~
bostonvaulter2
One reason to go with components over a switch statement is so you can render
a specific component on all '/about' pages along with an additional specific
component on all '/about/team' pages. With a switch statement you can only
match a specific branch.

~~~
kfinley
You can still do nesting within a case, or add another case 'about-team': and
add another {var} to your component. That's essentially what RR would do.
React Router approach is probably a little cleaner, however.

------
AgentME
I'm surprised at the number of negative comments about updates. You don't have
to update. It will keep working. It's not like you're going to miss out and be
left behind from some vast and vibrant react-router ecosystem. It's just a
couple components that match strings up with other components and then barely
matters to the rest of your application.

It's exciting that there are people out there experimenting endlessly to
figure out the best APIs to build things with. Just because someone comes up
with one idea doesn't mean they're wed to supporting it forever. Or for any
amount of time: react-router v3 is open source and you can maintain it
yourself if you like it or just want to stick with it but want more.

~~~
Klathmon
No need to maintain v3 yourself, they will be maintaining it for you.

>We intend to keep supporting the 3.x branch indefinitely (published
separately on npm to aid in migration), although there will likely not be any
future major versions based on that code. 4.0 is the future, but we won't
leave you hanging if you want to stick with 2.x/3.x.

------
zachrose
Disclaimer: I am a former Backbone-using developer who hasn't done much front-
end work since React became so dominant. I just don't understand this project.
I'm commenting to explain my confusion in the hopes that somebody else's
perspective can help me see why React Router is helpful.

When React came out it was billed as just the "V" in client-side MVC. While
just about everybody has their own understanding of MVC, my interpretation of
the "V" was that it was about things you can see. So React was going to take
my data and maintain a UI based on that data without thrashing on the DOM.
Cool!

But nobody seemed to do that at first. They put HTTP requests all sorts of
stuff inside the React component, and then handled the requesting, processing,
and rendering as internal details to the component.

Then the Flux idea came around, which was (I think) to brand one-directional
events as "actions" and then smartly cache/reduce an ongoing stream of actions
into a single data structure that represents lots of potentially disparate
parts of your application. This also made some amount of sense to me.

Surely there would be lots of things that could create actions: incoming DOM
events representing a user's intentions, ajax responses that have potentially
new facts about the world, websocket events, signals from the camera and
microphone, and anything else that might cause a change in the overall state
of the page. With the possible exception of DOM events, which the view should
quickly translate into meaningful actions anyways, these actions are really
not related to the "V" at all.

So what benefit would I get from authoring the logic of URL-change handlers in
JSX? Wouldn't it be nicer to write some JavaScript that handles those events
and transforms them into actions?

~~~
sotojuan
The V in MVC was a mistake IMO and it was eventually removed from their site.

~~~
zachrose
Why do you think it was a mistake?

~~~
sotojuan
It's not how most people end up using React and it just causes confusion.

~~~
morenoh149
Flux (the data management architecture for react apps) eschews MVC altogether.
Maybe that's related.

------
Klathmon
They are going to support the old versions "indefinitely". The FAQ doesn't
mention it, but their Release notes[0] does. I'll copy the relevant part here:

>We intend to keep supporting the 3.x branch indefinitely (published
separately on npm to aid in migration), although there will likely not be any
future major versions based on that code. 4.0 is the future, but we won't
leave you hanging if you want to stick with 2.x/3.x.

[0][https://github.com/ReactTraining/react-
router/releases/tag/v...](https://github.com/ReactTraining/react-
router/releases/tag/v4.0.0-0)

------
mbrock
I think if/else statements with regexps, returning components, are my favorite
"routing solution".

Ridiculously simple, no dependency on someone else's weird ever-changing ideas
about declarative composable component-based route paradigms, no need to write
your routes in a markup language, everybody understands it, extensible as
hell, trivial to debug—it's a glorious cascade of beautiful advantages.

Try if/else today!

------
guntars
It's interesting just how long it can take to unlearn habits from previous
programming experience and find a way to do things in harmony with the current
tools you're using. Probably the more experienced and senior you are, the
harder it gets.

~~~
nine_k
To the contrary, it gets easier. Many of the new things are older things I've
seen in different contexts. Some of the new things are a welcome relief from
shortcomings if old tools.

------
brendonjohn
It took me over a week to grasp how routing would combine with redux, async,
react and then server side rendering.

We got there, but there just hasn't been a simple (to reason about) way to do
this in javascript. Acknowledging that the current library is fighting (I
would call it an anti-pattern) with react is probably a good step. Thanks
devs!

------
patwolf
One of the things that's burned me in the past with React Router is not just
that the API changes from version to version but that documentation I'm
reading at any given time doesn't indicate which version it refers to. I've
wasted time trying to debug why things weren't working the way the
documentation stated only to find that I was reading the wrong version of the
documentation.

Some advice for anyone that hosts docs outside of the git source tree, make
the version information clear. For example, the express documentation
[http://expressjs.com/en/api.html](http://expressjs.com/en/api.html) states
very clearly "4.x API".

------
breatheoften
Looks interesting -- what's up with that Redirect component though ...? That
seems all kinds of strange to me conceptually.

My mind is trying to justify it like this: Render me a component that's going
to manage the state involved in transitioning to a new page ... I guess that
kind of makes sense -- since a redirect is an inherently stateful process.

~~~
marshallford
I too am confused by this. I found this GitHub issue [1] when searching for a
withRouter HOC replacement.

1\. [https://github.com/ReactTraining/react-
router/issues/3847](https://github.com/ReactTraining/react-router/issues/3847)

------
elmigranto
Okay. I understand that this library is kind of "learn as you go" project,
much like React itself. But not make it on the third go… This is a part of
React ecosystem that has not been reasonably "solved" (kind of like `redux`
"solved" state-management good enough, or `express` solved server-side for
Node good enough; and there are lots of iterations on those two), so if you
want to start a popular OSS project, think hard about routing. (But really,
think hard first!)

I also like this joke from github readme:

> Versioning and Stability

> We want React Router to be a stable dependency that’s easy to keep current.

------
morenoh149
I'm seeing mention of [https://ui-
router.github.io/tutorial/react/helloworld](https://ui-
router.github.io/tutorial/react/helloworld) and
[https://github.com/wesleytodd/nighthawk](https://github.com/wesleytodd/nighthawk)
does anyone have experience with
[https://github.com/router5/router5/](https://github.com/router5/router5/) ?

------
boubiyeah
I use routers that aren't coupled to the view layer, thank you very much.
routers can actually be pretty simple.

~~~
colinramsay
Example?

~~~
wesleytodd
[https://github.com/wesleytodd/nighthawk](https://github.com/wesleytodd/nighthawk)

^^ This is the one we developed on my team. No view coupling, uses industry
standard underlying components (Express Router), and layers on top of existing
applications seamlessly (aka, no view tie in points, just anchor tags).

~~~
ChrisCinelli
What does it add on top of [https://github.com/wesleytodd/react-express-
middleware](https://github.com/wesleytodd/react-express-middleware) ?

~~~
wesleytodd
That middleware is actually just a isomorphic render method, which uses
express's render on the backend and react's render on the FE.

So that middleware actually requires a solution similar to what Nighthawk
provides. The point was to keep the routing and the rendering separate, unlike
what react router does.

------
rcurry
Anybody else having trouble with the link that they provide to their "Quick
Start" documentation?

I can't see all the code unless I zoom out on it:

[https://react-router-website-xvufzcovng.now.sh/quick-start](https://react-
router-website-xvufzcovng.now.sh/quick-start)

~~~
timdorr
That version of the site will work best with Chrome. The newer version will
fix for Firefox: [https://react-router-website-
xvufzcovng.now.sh/](https://react-router-website-xvufzcovng.now.sh/)

The next build (now.sh versions URLs) will have both working. Sorry about
that!

~~~
bostonvaulter2
Quick question, is it necessary to render a single component within a Router?
All the examples except the quick-start example seem to do so.

~~~
timdorr
Yes, because we have to render props.children and normally Router is right
under or near ReactDOM.render(), which only wants a single element from the
component from the top of the tree. We were inserting a <div>, but that would
screw over React Native users. So, unfortunately due to the structure of
React, we have to enforce a single child.

This is improved a little bit in git, where we do a React.Children.only check:
[https://github.com/ReactTraining/react-
router/commit/5a74d46...](https://github.com/ReactTraining/react-
router/commit/5a74d46a9fcf1b9663ba42b238ba6dd4584983ab)

~~~
bostonvaulter2
Ah yeah adding that check should help. I wasted a good 20 minutes trying to
figure it out the other day. Can the quick-start example be updated to have a
single child? I would submit a PR but I was unable to find the repo.

------
jtchang
So if you don't want to use react router what do you use for react client side
routing?

~~~
wesleytodd
[https://github.com/wesleytodd/nighthawk](https://github.com/wesleytodd/nighthawk)

My team uses this, we built it in response to most of us not liking the React
Router methodology, and already using Express, it seemed like a good route.

~~~
ChrisCinelli
What does it add on top of [https://github.com/wesleytodd/react-express-
middleware](https://github.com/wesleytodd/react-express-middleware) ? Are you
using it for server side rendering, too?

~~~
wesleytodd
See above:
[https://news.ycombinator.com/item?id=12514798](https://news.ycombinator.com/item?id=12514798)

------
fibo
I started using react-router recently and I felt that some things were missing
(like passing props to routes). I hope this release Will improve the API.

Thanks to all the devs that keep moving forward this wonderful ecosustem.

~~~
scarlac
As far as I can tell, that part hasn't changed. But you're free to pass a HOC
(Higher-Order-Component), ie.

    
    
      <BrowserRouter>
        <Match pattern="/" component={() => <MyComponent someProp="yep" someOtherProp={myOtherGlobalVar}/>}/>
      </BrowserRouter>

------
connorelsea
I am new to React Router. What is the alternative to managing routes on the
front end when you're using only React (and redux) on the frontend and not
routing on the backend in express or something?

------
psibi
Is there any other Router library for React which has a stable API ? We are
most likely to include a router library in our application soon and we don't
want something which changes frequently.

~~~
ng12
I've been asking myself if I really need it. The very first React project I
ever did I managed URLs by myself like I would have done in jQuery/Backbone.
Honestly, I don't remember it being that bad.

------
adregan
During the past year or so, as the "standard" React architecture has come to
embrace keeping application state together in a global store, react-router
looks a little out of place. Why should it maintain such a crucial part of the
application state separate from the rest of the app? In reality, the best
pattern for the future probably looks a lot more like "redux-router" than
react-router.

------
hamandcheese
I recently noticed that reactjs/react-router redirects to ReactTraining/react-
router. Does anyone know why that is?

~~~
Touche
Because they changed orgs and Github redirects it for you.

~~~
hamandcheese
Yes, but why did react-router move out of the reactjs org?

~~~
spicyj
It's always been Michael and Ryan's project. They wanted to move it back out
-- I assume to help promote their training business -- and that seems
perfectly fair to me.

~~~
bronson
They maintain React Router to help promote their training business? I suppose
that could explain its instability.

~~~
spicyj
No, that's not why they built it (they built it before starting their
business) and I don't believe it's why they maintain it.

~~~
bentlegen
I just want to point out that whether they built it before or after starting
their business doesn't really matter. It's definitely a part of how they
promote React Training today (see: moving the project to the ReactTraining
GitHub organization, or how many times react-router is mentioned on their
marketing website).

Not that I have a problem with that; all the more power to them. Especially if
it helps support development of these libraries.

------
6mirrors
After using react-router more than a year, I have to say it's a helpful lib,
but the doc and the authors are not ready for serious business.

------
beefsack
It's interesting that a large amount of churn seems to be an unfortunately
common trait of frontend libraries.

------
antihero
Just a note: You can't scroll the docs (Chrome OSX).

~~~
timdorr
Sorry about this! If you use the older now.sh link, it will work:
[https://react-router-website-uxmsaeusnn.now.sh/](https://react-router-
website-uxmsaeusnn.now.sh/)

It's fixed in git, Ryan just needs to push a new build.

------
elliotec
[removed]

~~~
sotojuan
How so? He seems very nice to me and people in general like him and his
course.

------
meira
Great! I removed React router from a project yesterday, now it seems an even
better decision.

Edit: I didn't have any big issue with React router and don't dislike it. It
just don't work well with clojurescript/rum. I'm now using a cljs lib called
'bidi' for bidirecional routing (data only) and a small logic to change
content reactively based on selected route.

~~~
tptacek
Same! react-router is the only thing I've dealt with in this ecosystem that I
truly, viscerally disliked.

------
joshkpeterson
As someone just arriving to React - should I just learn React Router v4?

~~~
mjackson
Hi, one of the authors of the router here :)

Try to insert routing only when you need it. When you're ready for a router,
react-router is a great choice. Lots of people are already using it with great
success, and you'll find a great community of people willing to help you out.

~~~
brendonjohn
Yes, I like this. It's important to learn what react is and why it's good for
handling state in a component before you start trying to build the routing of
a full web app.

