[1.0] Upgrade React Router to v4

[KyleAMathews]

Fixes #937

Current status, rendering things correctly with the development server.

[gatsbybot]

Deploy preview failed.

Built with commit 48e2735

https://app.netlify.com/sites/using-drupal/deploys/5914ac5c8ebdd97352abb566

[KyleAMathews]

Deploy preview failed.

Built with commit 48e2735

https://app.netlify.com/sites/gatsbyjs/deploys/5914ac5c8ebdd97352abb562

[KyleAMathews]

Deploy preview failed.

Built with commit 48e2735

https://app.netlify.com/sites/gatsbygram/deploys/5914ac5c8ebdd97352abb564

[MoOx]

Curious to understand how do you plan to handle recursive routes. Any detail to share?

[KyleAMathews]

@MoOx every page component is at the heart of things and it can have 1 or 0 layout components. Generally sites have 1 to N page components and often just 1 layout component (layouts/index.js is the default layout component if a page doesn't specify one specifically).

Up to now v1 of Gatsby hasn't supported multiple levels of layouts (which v0 does) but in this PR I'm actually adding back support for that. Basically a layout will be able to indicate that it has a parent layout component. So when Gatsby creates its routes it'll just recurse up the layouts to the root component and then render that hierarchy.

[MoOx]

Oh so Gatsby generate the routes for react-router... I was thinking user were able define their own routes :) So what the point of using react-router?

[KyleAMathews]

Something's gotta handle routes and components.

Also RR v4 makes it far easier to embed client-only routes within a larger static Gatsby site. meetfabric.io, the company sponsoring the upgrade, is doing exactly that as they'll be using Gatsby for both their marketing website as well as the client app portion of things.

[KyleAMathews]

It's possible at some point we could make RR an optional dependency to slim things further but not today.

[fabien0102]

Refactor proposition:

const routesData = pages.reduce((mem, {path, componentChunkName, layout, jsonName}) => (
      { ...mem, ...{[path]: {componentChunkName, layout, jsonName}} }
    ), {})

https://codepen.io/fabien0102/pen/MmrqKe?editors=0011#

[KyleAMathews]

I like it! I'll make that change. Object/array spreading makes reducing quite nice!

[KyleAMathews]

This PR has two breaking changes.

• Gatsby now looks for a HTML element with an ID of ___gatsby to render itself instead of the current react-mount. You'll need to change that in your html.js. Gatsby may or may not stay React only in the future after all ;-)
• The "default" layout component should now be at layouts/index.js not layouts/default.js. A quick move over will fix things.

[KyleAMathews]

Ok, this looks ready to go in.

One more breaking change — this.props.children in layout components is now a "function". I spent hours trying to upgrade gatsbygram yesterday before realizing this was the only option basically. The problem is that when you load Gatsbygram and click on an image, it loads a modal to display the image but leaves the background the same. So basically the gatsbygram layout needs to say, "keep rendering / despite us having navigated now to /path-to-image/.

If this.props.children is a function, then this is easy. See the code diff for all the gory details https://github.com/gatsbyjs/gatsby/pull/940/files#diff-abbddb44eecd9dea4fc2d307be2d7b9dR157

See this article for a good intro to children as a function https://medium.com/merrickchristensen/function-as-child-components-5f3920a9ace9

This is an easy change though. Just change this.props.children in your layout file to this.props.children().

[KyleAMathews]

This PR also adds support for client-only routes (and an example site showing this off).

Basically how it works is that a page can have a matchPath in addition to its path. The path is what's used for server rendering but in the client, matchPath will be used in addition to path for deciding which page component is in control.

So say you had a marketing website and client-only app in the same Gatsby site.

Marketing pages would be at paths like /, /blog/, /pricing/, /features/, etc. The app might be at /app/. But the app also has a bunch of sub pages like /app/settings/ and so on. But these shouldn't be rendered on the server, just on the client. But without modifying anything, when you try to navigate to /app/settings/, things will break because Gatsby will try to find that page and fail. So what you do is add a matchPath to the app page like /app/:path. Now for any subpath of /app/ Gatsby will still pass control of the site to the app page.

The easiest way to add a matchPath currently is in gatsby-node.js using the API onUpsertPage which is called whenever a page is added.

You'll also need to make sure that whenever a user loads from the server urls like /app/settings/ that you load /app/index.html.

[KyleAMathews]

I had some tasks for this upgrade that I'm not going to get to right now. Multiple layouts + layout hierarchies, and layouts w/ graphql queries. This is very doable just ran out of time + the API could be tricky so it deserves a deeper dive + discussion.

[KyleAMathews]

Create an issue if you're interested in working on it and I'll write up some thoughts.

[KyleAMathews]

I snuck in some optimizations. gatsby-plugin-google-analytics dropped react-ga as a dependency as it had a ton of code we don't need. gatsby-plugin-catch-links dropped a dependency and inlined a simple version that does exactly what we need.

[KyleAMathews]

This is the URL of the example site I built for client-only routes https://client-only-paths.gatsbyjs.org/