Can’t access markdown frontmatter data within _template.jsx

[JLongley]

I want a way to render the title, date and author of a blog post from the markdown front matter. It seems like a template would be a natural way to solve this use case:

/blog/_template.js
/blog/post1.md
/blog/post2.md

However, as far as I can see, the front matter data properties are not exposed to the template.

The supported solution, AFAIK, is to use the wrapper a la #135

/wrappers/md.js

To do so, I must implement ugly branching logic within that file to first check I am under the /blog/ path, and then I can implement my template with the data made available to

this.props.route.page.data

Since paths are just based on the file structure anyway, using the template file for this use case seems much more natural. As it stands, I am left scratching my head as to what the purpose of nested _template.jsx files even is.

[KyleAMathews]

_template files are for parts of site that are shared across pages e.g. the classic example would be a header. Wrappers are to “wrap” data from static files inside react components as in Gatsby, every page has to eventually be a React component. The markdown wrapper (and other wrappers) is called for every markdown file.

Nested _template files are useful if a sub-section of the site has its own navigation or other shared section. The left sidebar on the docs section of the documentation starter is an example http://gatsbyjs.github.io/gatsby-starter-documentation/docs/ && https://github.com/gatsbyjs/gatsby-starter-documentation/blob/master/pages/docs/_template.jsx

[danielo515]

I'm on the same situation.
I don't feel that it is natural to change the markdown wrapper code just to change how I want to render certain section of my site. I want to be able to write the content of several sections of my site on markdown, and change how do they look using templates. With the current behavior is very hard. I would like to receive the markdown data on the template and decide how to render it on each subsection using different _templates.

Regards

[danielo515]

I found a way to get the required data in the template, but it is a bit ugly.

I noticed that the children has a props property, which in turn has a route that holds all the page information. So you can do this from the template: this.props.children.props.route.page.data; and access the page data. However, this seems weak, and I'm not sure if it is recommended. I would like to hear @KyleAMathews answer.

Regards

[KyleAMathews]

@danielo515 if you want to add a PR to pass the page data directly to templates as well, we could add support for that.

[twitchett]

Just want to add a 👍 to this proposal. I only just started experimenting with Gatsby so I'm not terribly familiar with it yet, but coming from using Jekyll, this is one of the first things that I tried to do. Hence landing on this thread. It seems natural that the template should know about the properties of its content, in order to keep display logic related to that content in the same place.

[danielo515]

Dear @KyleAMathews that will be cool. Where should I start looking at ?

[KyleAMathews]

@danielo515 of it's already there haha, I haven't used Gatsby 0.x forever.

checkout this.props.routes.pages in your _template.js.

[danielo515]

Dear @KyleAMathews , I checked already, and I saw it, but that requires an, in my oppinion, unnecessary filtering. Don't get me wrong, having that information is very useful, but I would like to have something easier to access tho the data of the current page, like this.props.children.props.route.page.data but shorther, maybe this.props.route.page.data

[danielo515]

Hey!
I just noticed there is something close to what I was looking for. Under props, there is an array at routes, that array seems to contain information about all the routes between the index and the current one. For example, in my case it was an array of 3 objects, containing information about path:/ path:/webapps/ and path:/webapps/columnator. The third element of the array corresponds to the current page, and have all the information required, including the page property.
Is this behavior intentional or is it maybe some kind of collateral effect of using react router?

[KyleAMathews]

@danielo515 collateral :-) though picking good libraries with good designs mean you inherit lots of goodies that fall out of their good design.