[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.

[hokkos]

Thanks you are the only one talking about the new api style here, it seems very interesting. It is like the dual of the previous version where all routes were declared in the same place, here we dispatch the route fragments in the app. It will simplify nested routes, but I hope it won't "infect" the app with routing concerns too much. I've ranted before about react-router, maybe they should call it another name this time, I hope they will keep on maintaining the v3.0, the switching cost will probably be too much for my app.

[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.

[timdorr]

It's more that you can get the information about the state of the browser or server's URL down deep into the component tree and then more easily act on it (with a few components, rather than a larger case statement).

It's basically idiomatic JS vs idiomatic React/JSX.

[kfinley]

That's a fair point. Kind of like adding a redux @connect in a child component.

Edit: To the idiomatic point. The first thing that struct me when using React, was that instead of having to use a custom Component for a for loop I could just use someArray.map(). I see this as a similar situation.

[seangrogg]

This is actually a naive version of what I've been doing since I had to unwind a react/router/redux application once (I've since moved the components into an object and just reference it as component[value]).

While React-Router had a lot of great convenience features I found that it was surprisingly easy to roll my own redux-compatible version that fit my personal needs with a few lines of code and no additional dependencies.

[danabramov]

For testing, you can wrap your component in <MemoryRouter> and that will work just fine (including links and redirects, for example).