exporting that from the same file as a React component will make the config information available to the component as a data prop on the component. For instance, the title attribute could be referenced as props.data.site.siteMetadata.title.

Migrate wrapper components to template components

In v0, there was the concept of “wrapper” components that would render each
file of a given file type. E.g. markdown files would be rendered by a wrapper
component at wrappers/md.js and JSON files wrappers/json.js, etc. Data
would be parsed from the files and automatically injected into the wrapper
components as props.

If you’re not using wrappers in your site, feel free to skip this section.

While this proved often intuitive and workable, it was overly prescriptive
and restricted the types of pages that could be created due to the required
1-to-1 relationship between files and pages.

So for v1, we’re moving to a mode where sites must explicitly create pages
and create mappings between template components and data.

Gatsby’s new data system turns your data into a queryable database. You can
query data in any way to create pages and to pull in data into these pages.

These mappings can range between straightforward and complex. E.g. a markdown blog
would want to create a post page for every markdown file. But it also might want to
create tag pages for each tag linking to the posts using that tag. See this issue
on programmatic routes and this
blog post introducing work on v1
for more background on this change.

So we’ve now generated the pathname or slug for each markdown page as well as
told Gatsby about these pages. You’ll notice above that we reference a blog
post template file when creating the pages. We haven’t created that yet so
let’s do it.

This is a normal React.js component with a special Gatsby twist—a GraphQL query
specifying the data needs of the component. As a start, make the component look
like the following. You can make it more complex once the basics are working.

At the bottom of the file you’ll notice the graphql query. This is how pages
and templates in Gatsby v1 get their data. In v0, wrapper components had little
control over what data they got. In v1, templates and pages can query for
exactly the data they need.

There will be a more in-depth tutorial and GraphQL-specific documentation soon
but in the meantime, check out http://graphql.org/ and play around on Gatsby’s
built-in GraphQL IDE (GraphiQL) which can be reached when you start the
development server.

At this point you should have working markdown pages when you run gatsby develop! Now start gradually adding back what you had in your wrapper
component adding HTML elements, styles, and extending the GraphQL query as
needed.

Repeat this process for other wrapper components you were using.

html.js

This should generally work the same as in v0 except there are two additional
props that must be added to your HTML component. Somewhere in your <head> add
{this.props.headComponents} and somewhere at the end of your body, remove
loading bundle.js and add {this.props.postBodyComponents}.

Also the target div now must have an id of ___gatsby. So the body section
of your html.js should look like:

_template.js is now src/layouts/index.js

You should be able to copy your _template.js file directly making only one
change making this.props.children a function call so this.props.children().
The rational for this change is described in this PR
comment.

Nested layouts (similar to the nested _template feature) are not supported
yet but are on the roadmap for v1.