Creating a Layout for MDX

[00:00:00]
>> So let's do a new component in the components folder called post layout.js. In this post layout, let's import, everything is react from react, then we're gonna import link from Gatsby. Because I wanna add the ability to add a link at the bottom of every post taking you back to the full listing, and then we're going to import our layout.

[00:00:27]
And this is so that we can grab the content of the MDX post, and then I want to insert the details from the MDX post into our layout. So the way that this will work is we're gonna export a default function called post layout, and that is gonna get the children, which is just anything inside of it like the like the layout would.

[00:00:50]
And then we're gonna do something from Gatsby called page context. So before I do anything else, let's just show what this looks like. So I'm going to return the layout, and inside the layout we're gonna send the children, but then I also want to just stringify the page context.

[00:01:18]
This is one of my favorite debugging tools, when in doubt, wait, got to wrap this. No, that should be fine. What have I done? I'm missing a closing parentheses is why that's unhappy. Okay, so one of my favorite debugging tools when I'm trying to figure out what's going on in Gatsby is to just grab whatever comes out and enlist it.

[00:01:41]
So if you want to see everything actually this is probably even better, let's just do everything that's not children, let's stringify it underneath the post. So now that we've got this, we need to actually configure Gatsby to use it. So down in here where we have the layout, let's just change that over to post layout, and it's gonna tell us it needs to restart.

[00:02:05]
Okay, so that's restarted, and now we get a whole bunch of stuff. So this is what Gatsby is actually passing in to any given page. And because this is marked down we get a little bit extra, or MDX I mean. So first we get the path, okay, great.

[00:02:20]
We knew the path, we're happy about that, so we've got in here we've got the location, and that gives us all the things that you would get, this is actually coming out of reach router. So it's information about where we are and the state of navigation in our app.

[00:02:34]
Then we get down in some things that we don't really need to worry about. These are Gatsby things like our page resources, where the what the JSON is for the page. So this is if you want to see how much data is gonna get sent down with your your Gatsby files.

[00:02:48]
This is why it's good to validate that you're not sending a bunch of data you won't actually use. Information about the page like this is what the files will be called, what the webpack harsh etc. Static query results, so we're loading, remember we're using the header where we've got this query for the title.

[00:03:05]
And then, this is the SEO component that's got the query for the site metadata. The URI, and finally down here we've got page context. And so, what page context is, is when you create a page in Gatsby, there's all the way at the bottom of the stack where there's a node API, that Gatsby uses called Create Page.

[00:03:26]
And you pass in a path, you pass in a file that you wanna use as the template, and then you can pass in something called context, which is just an object. And whatever you pass in here gets provided in the page context object. And in the case of MDX, whatever you put in the front matter gets put into the context object when the page gets created through Gatsby.

[00:03:48]
So that means that in our layout, we can access this page context object, and pull out the title and description and date if we wanted to, to then feed into our SEO component. So let's actually do that here. We'll go into our post layout, and instead of the props we're gonna get the page context, and we don't need to destructure this anymore.

[00:04:12]
So instead what we're gonna do is we're going to get out the title and description from page context frontmatter. And down here in the layout, we're gonna set the title to be title, and the description to be description. Okay, so having done that, we can add our link back, so let's add a link to, and we're gonna do our blog role on the homepage.

[00:04:44]
Then I'm gonna use a left arrow HTML entity so that we can point back and just say Back. So what this gives us is now, we actually get the things that we want. There's the post title, and if we look in here in our description, If we can find it where to go.

[00:05:03]
Here's our description, and it shows us the actual description we wrote, and if I go back, let's go to the first blog post. We can see the same thing, so, here is our description, this is my first MDX blog post, the title is updated to say my first blog.

[00:05:22]
So now, that post layout is actually using the front matter data to update the search engine values. So with pretty minimal changes we're able to kind of wrap our layout and just do the little bit of abstraction that we need, so it'll still use our layout. And if we in the future want to add more fields to it, like we wanna add the date or we wanna add the Twitter author or something like that, we can do that.

[00:05:47]
We would just need to modify our SEO component, and then add the front matter fields and just pull them out here. So, if we wanted to add a new one we can pull out like the author field and we could we could use that then.
>> What's the max number of blog posts that Gatsby can handle without tears?

[00:06:06]
>> [LAUGH] Okay, so the thing about Gatsby is that it's not about numbers, it's about the amount of work that is being done. So if you take Gatsby and you feed it a bunch of files that have one word and no metadata and no images, it can handle thousands, tens of thousands, potentially hundreds of thousands.

[00:06:32]
But as you start to add in like images to be optimized, if you feed it raw images direct from your camera, and every image is 50 megabytes and has to be resized, it's gonna choke on dozens of pages. It'll take forever to build the site, so it's very much a matter of what are you asking each page to do?

[00:06:55]
And how much work does it have to do to get from the raw material to the end page that you're looking for. A good example is, if I'm pulling data from a third party API, and that API has a rate limit that requires us to only ask for 10 posts per second before it would block us from from asking for more.

[00:07:16]
And we asked for 1000 posts, we've just guaranteed 100 seconds of data loading for Gatsby to run. Now that's not Gatsby's fault, that's a limitation of the API. Where Gatsby does struggle is when you put tones and tones and tones of images in there. It will try to parse all of those, and it's pretty good at caching things so that it doesn't do work more than it needs to.

[00:07:40]
But it will it just, it's a problem that scales not quite linearly. I wouldn't call it a linear scale, but it's a challenge in that as you are adding more work to the Gatsby build pipeline, some types of things are gonna balloon very quickly. Like very large images, it'll slow down fast.

[00:08:04]
Number of text files, it takes a long time for that to start to bottleneck. So it's a little bit less about like hard numbers and a lot more about the type and amount of work that you're asking Gatsby to do as part of that build process. I know that's a very squishy answer, but unfortunately that's the best I got.

[00:08:22]
[LAUGH]
>> Someone commented that you could potentially host the data somewhere, and then and Gatsby can import the data at build time. And with web hooks trigger builds an incremental builds on Gatsby cloud which rebuilds what's changed, I don't know anything about that, but maybe you do.
>> I mean if you wanna get really clever like, here's again where I think if you find yourself working that hard to make Gatsby build, maybe don't use Gatsby.

[00:08:58]
It's one of those things where if you find that the vast majority of the work you're doing is getting the tool to cooperate, you're probably using the wrong tool. I think that you can, you could like pull the data down and have it in a JSON file that you refresh periodically with web hooks.

[00:09:16]
And you can check whether or not any data changed in a web hook to see whether or not it's time to rebuild the site. And there are ways to do that, like Gatsby version 3 introduced incremental build as part of the open source frameworks. So if you keep around the cache, you will get incremental builds as part of running Gatsby.

[00:09:34]
So later we'll deploy it to nalify and we'll I'll show you how we keep the builds or the cache between builds so that you get incremental builds on whatever platform. If you keep your cache folder it's gonna work, that's not like a Gatsby cloud specific thing. You can do things like pulling delta changes from your CMS and trying to merge all of that in, but, There's a reason that people say that there are two hard problems in computing, and that one of them is caching.

[00:10:10]
And I think that trying to manage your own cache is going to be not worth it in the long run. You will end up causing yourself problems, you'll do something clever with your cache. It'll go wrong, it'll get out of sync, your site will go down, you'll get paged on a Saturday night.

[00:10:30]
Like it's anytime I've seen somebody build a clever workaround for making Gatsby faster, they've ended up regretting it. So instead, Look at, what data do we actually need? What data are we querying for that we're not using? Are images being served at 10 megabytes each, and Gatsby is having to parse all those down?

[00:10:53]
Are we holding on to the cache folder in between builds? Like how often are we running Gatsby clean? How often are we deleting the cache? Because each of those things is gonna slow down our build times. A lot of people I've seen have this bad habit of running as part of their build Gatsby clean end to end Gatsby build?

[00:11:09]
Please don't do that. You're guaranteeing the slowest possible build, and Gatsby works really hard to to not, like to make that cache work. So there's a lot of things that if you just, Look at what you're feeding Gatsby, you can make it fast without having to resort to complicated workarounds.

[00:11:30]
And if you find yourself resorting to complicated workarounds, it may be worth considering a different build tool. Because ultimately, it's if the majority of your work is fighting your build tool, then you're probably not using the right tool. That's a little rantier than I intended to be, but I've definitely seen a lot of people cause themselves a lot of pain by digging into this and thinking they can outsmart Gatsby's build system.

[00:11:58]
Trust me, it's way too complicated, you're not gonna outsmart it, you're just gonna break it. If you are getting inconsistently like something's not working, you can do a comparison between the code that's on the progress branch, that's been pushed. Let me make sure it's up to date, yeah, everything that we've done so far is pushed up.

[00:12:18]
So check that, you can pull the latest changes to make sure that the code that you've written matches the code that we've been writing. Otherwise, yeah, the front matter stuff is kind of built in. There's not a lot if you've got these fence code blocks, there's not a lot that we can do to make that not work.

[00:12:41]
So if it's written like this, it should be getting picked up,assuming the config in here is the same. How can you access the variables from the MDX file? We're gonna get into that, I will show you in a couple steps, we'll get some some of the props, and work with them a little bit.

[00:12:59]
The short version is that it that you can just access props, the way that you would in a react component inside of MDX, but we'll actually walk through building that in a little bit.