Hasty Treat - Gatsby Tips

Welcome to syntax in this Monday hasty treat. We're gonna be talking about Gatsby, and, I'm excited. I love Gatsby. In fact, I I had one of the first courses on Gatsby in the entire YouTube. So I've been on the Gatsby train for a long time, a big, big, big fan. I know Wes is a huge fan too. He just built his site in Gatsby. My name is Scott Polinski. I'm a developer from Denver, Colorado. And with me as always is the Wes Bos. Hey, everybody.

Hey, Wes. This episode is sponsored by one of our longtime sponsors over here, and that's LogRocket.

No. I'm talking about logrocket.com.

Now you're gonna want to check out log rocket.comforward/ syntax.

Get 14 days for free of LogRocket. Now what is LogRocket? Well, it's the service that allows you to see your bugs and errors happening as they happened. It's a video session replay. It's very, very cool. It's one of those services that you would have wish you would have had in any project you were doing because anytime anything goes wrong, you often ask mhmm. Maybe you look in your bug tracker to see maybe what browser or what what some of the code was that hit it, but this actually gives you a video of the event happening. Imagine being a detective and having a video of the murder take place. That is really what this is doing. So head over to logrocket.comforward/syntax and get 14 days for free. Check it out. Very, very cool service.

So, Wes, Gatsby tips.

So these are just gonna be things that after building a couple of Gatsby websites Yarn little tips JS the title said. So the first one we have here is to make a reusable SEO component that sets all of your defaults. So what I found myself doing was on each of my pages, I would use React Helmet to set all the head metadata. And you in there, you'd have your Open Graph meta tags, Twitter specific meta tags. You'd have, SEO meta tags. And, like, I find myself using the same strings and images maybe 2 or 3 times over it, and then I also found for pages that I didn't specifically have anything special for that other than the title of the page, then I I I would find myself being like, I'm not sure what to to set up. So what I do is create a SEO component that in turn uses React Helmet, and then set all of your defaults in there. So your default title.

React Helmet will also allow you this is something I didn't know.

React Helmet will allow you to set up a title template.

So if if all of your pages are, like, about dash Wes Bos, uses dash west boss, like, everything is dash west boss, Red Helmet will allow you to set a a template for that. So you only have to pass in about and uses or the the name of the blog post or the name of the page, and then it will render that out for you. So set a whole bunch of defaults, pass in titles and images and thumbnails and stuff into your SEO component, And then finally, allow yourself to pass just additional, meta tags that are spread into the SEO component. So meaning that you can also pass additional tags like you would to react helmet, and then those will just be put later on in your SEO component. And those will overwrite anything that you you wanna overwrite.

Yeah. I think that's the important thing is that the the React ESLint will overwrite. It's not like you can only have 1 of them. So my general strategy personally for React helmet is to have one at the, like, the sort of app level that is just like a blanket covers every page. Right? And then as we go, I make them more specific based on different trees of the application, whether or not it's, like, in this layout or this layout or whatever. But as these trees go down, you can make your React Helmet as specific as you want. Fantastic. That's a, like, a low key super duper duper constantly useful, like, every project kind of component that is is React Helmet. So next 1 is going to be, when in doubt, stop the build and restart.

Too many times, I think people had issues where maybe a plug in's not being recognized or maybe they gooshed something up in the config. Either that or Gatsby is just behaving oddly, not what they're expecting to have happen. Now because Gatsby sometimes, it it needs a a restart here where you have to cold stop the build so that the node processes actually, rerun, that's what you gotta do. So, for me, when in doubt, stop the build and restart.

And it looks like you have a a little additional notes here too. Yeah. Just

sometimes Gatsby gets into a weird space, and you just gotta start over. Cash involved.

The the reason why Gatsby build is is so instant is because there's a massive cache.

And sometimes it gets a little bit weird, so you gotta just clean it out. So just run Gatsby clean.

I sometimes go as far to just Tolinski your node modules folder, delete your package lock file, re npm install, and restart.

And even though that sometimes takes a couple minutes, that will often fix some of these weird issues that comes along.

Next one we have here is to use, ES modules everywhere. So one, like, weird thing about Gatsby is that Gatsby Node and Gatsby what is it? It's Gatsby node, Gatsby config, and Gatsby SSR.

Those are all done in common JS because they're they're Node files. Right? And then it's annoying if you wanna share those with Gatsby browser or or anything like that. And, also, like, you're writing ES modules in React, but then you have to write common JS in the config files.

And what I've been doing for almost a year now is using Wes, and ESM will allow you to mix and match CommonJS and ES modules.

So I've just been writing ES modules everywhere in every file and sharing them amongst the files.

And, it's great. There's you can look at my Wes repo on github.comforward/wespossforward/wesposs Wes an example of how that works. I won't say the code here, but until Node JS done with ES modules and Gatsby will allow us to use ES modules, this is a really good solution.

Cool. And mine actually kinda goes along with this, which is to run the build locally to troubleshoot production issues because this the reason why this goes along with this in some regard is that I think, there's sometimes when people first start writing this stuff, they might not have even written any Node. Js code specifically or maybe they're they're just thinking about React. Right? This is a front end thing. This is a front end result.

And what you you don't often think about is, hey.

There is Node things that are happening and taking place, and at the end of the day, your entire application needs to compile in Node. Js, right, because it's it's running your that's how it generates the static build, is that it runs the site in Node and and creates actual HTML files from that. So my tip here is do not forget to run the build and then serve the build locally as a production build before deploying Because sometimes people, they get all done with their project, and they they just say, okay. I'm gonna get commit, brought up to Netlify, and then, oh, it's not working on Netlify. And now now I think it's a problem with Netlify. Little do I know that I wrote some code that's maybe I used to, like, a a window dot or something, and I broke the the whole thing. These are way easier to solve ahead of time on your local machine, without having to worry about whether it's being hosted or whatever. So just make sure you run that build before you you push it up. Next I have is

Scott like 2 options. So Gatsby doesn't have any specific layout, any ways to to to do a layout. You just have to create your own layout component and wrap your components in it. So my 1st tip and my 2nd tip are gonna contradict each other. So first one is wrap your layout automatically in in Gatsby SSR and Gatsby dash browser. Those 2 file files will allow you to hook into, wrap page element and wrap root element.

I think what I've I've read is wrap page element is inside of your providers, and wrap root element is outside of your providers.

So if you're doing layout, you you would want to put them in wrap page element, and that will every single page that you have will be wrapped in this specific layout, and there's no need to manually wrap every single page in that.

So the the whole wrap page element and wrap root element things are definitely topics that that seem scarier than they are at first. In fact, all of the additional sort of little API things in Gatsby are scarier than they are than they actually are. So, learn that stuff. You know what? Gatsby has a a page. Was it just like the, in their documentation let me see if I can find the exact page.

If you had to Gatsby site and then you click on docs and then you click on Gatsby API Learn all that stuff. There's a lot of really useful stuff in there. It's gonna come in handy. So even if you're just building something basic, you wanna get better at Gatsby, you're asking how to get better, that's how you get better. You'll you'll learn this stuff. Yeah. Just read all of it, and then that gives you a headspace of what are the possible

life cycle methods that you can hook into, and they will definitely come in handy when you need it. So my my other tip is the flip side of that is consider just manually adding the layout component to each page if you want that.

So if you don't want every single page to have a layout like, I ran in a situation Wes, like, if I want Wes/ like a microsite or a custom custom URL that's still within my Gatsby site, and I don't want it to include the entire nav and footer and everything that is in my layout. If that's the case, then there's nothing wrong with just manually wrapping a layout component on every single page where you need it and then just not doing it in the rest. Let's I'm just thinking about that. You know, one, like, really cool thing I I like about that is, I once accidentally wrapped my website twice in a layout component. I did both of the ones I talked about, and it worked. Like, I just had the whole layout twice. And I was like, that would have never have worked in WordPress land because the WordPress land is, like, the the logic of setting up headers and all of that, and the template are so tightly bound.

And in Gatsby, it's just what it looks like, and I I could wrap it 6 times if I wanted and have 6 navigation. Obviously, I don't wanna do that, but I just did that by accident.

That's really cool.

Some people would see that as a fault because they're they well, you're using this incorrectly. It should break. I don't know if I'm of that mindset, but I I definitely think that is is like a a positive in my mind. You could put your nav wherever you want if you wanted to put your nav. Flexibility.

Yeah. It's pretty cool.

Yeah. Another one here is along the lines of layouts. Now layouts and as they pertain to animations in in Gatsby are kinda difficult.

Animations. But Gatsby the way Gatsby and Next. Js do things with their their routing based is, unfortunately, it requires, like, basically, most of your your page to mount and unmount on page change, right, which is one of the reasons why they have the whole v one layout plug in or whatever from the old Gatsby version layout because people liked that way of doing things.

But Node we have to use this whole wrap root element and wrap page or wrap page element, and those are the types of features that you're going to want to use if you're getting into interface animations and transitions.

So just throwing an animation or an interface transition into your page or component is not a recipe for success. You kinda need to orchestrate it a little bit with Gatsby considering that there's going to be time to unmount and things like that. So if you want to have any interior pages or elements animate themselves, you kinda have to orchestrate it from the root element or page element layout wrapper that you've created JS something that is not going to get un mounted or mounted on everything. That way, you can maybe throw in a little delay here while the internals animate out in some sort of custom way, or you're throwing on maybe, like, a framer motion animated routes kinda situation that is taking place on the container itself.

Good

tip. My next one is one of these hooks that Scott was just talking about is, use the on create page to pass context to the layout. So on create page is a hook in Gatsby. And when your site is building, it will call that and it allows you to step in and you can do whatever you want. And in my case, I wanted to pass some additional context to my layout Scott JS component.

And what I did there is I I took the page's path. You have access to the whole page and all the data and everything like that, and I just checked if the path matched. In my case, it was thumbnail.

And if it was a thumbnail page, then you can just say page Scott context dot whatever.

And that allows you to if you ever need to need to send some additional data, over to your page, you can do that via the on create page hook.

I think those hooks are largely underutilized.

You Node? Under underutilized JS in, like, there's a lot more advanced functionality you can accomplish fairly easily with them as long as you just learn them. So, yeah, good one. Last one for me here is that you don't have to query for everything. You know? It's it's funny. I think is is it the example that shows that you're querying for metadata? I'm, like, getting it confused with the others' content or,

Gridsum and whatever. Like, that's what they show you as, like, the ESLint introduction to, rating queries JS type this text into this file, then query that exact same text from the thing. And I get that they're showing you a very simple intro to sourcing data, but it seems kinda silly not to to have to just type text into a file, and then it goes into the API. And then and then you gotta clear that. Yeah. I think sometimes people get the false impression that, like,

you gotta do that stuff. But to be honest, if something is output only a couple of times or it's not going to change, it's the name of your website or it's hard coded text or maybe it doesn't need to come in from an API. A lot of these sites that we're building with Gatsby, they don't have a CMS back end. It's just a site. Right? Put that stuff. There's no reason not to. If your site doesn't need a person that modifying and updating the content, I would not reach for a CMS back end. Right? I'm not gonna reach for Contentful or or WordPress or any of these things because it gives you not only, like, a ton of overhead in all sorts of ways, it just makes the entire process that much more complex. So if you don't need that content editing, keep it in code. It's gonna be way easier for you. Last tip I have here, I've said this before,

use if you've got lots of images and you're finding your build times are very slow, you can use Gatsby Parallel Runner, and that will offload the image generation to Google Cloud, and that will make it much faster. And that's why I use it on my own site. And there's also, like, Cloudinary, Sanity Image. All of those work with the Gatsby images as Wes. So that's that's an option as well. And and if that's the case, you don't have to generate any images on build time. You just they're just done on demand, which is pretty nifty.

Nifty.

Yeah. I love this. This is a lot of great tips on, on one of my favorite platforms, Gatsby.

And if you don't know Gatsby, give it a give it a real hard look. If if you're just a reactive novice or any of those things, don't worry because, man, you don't have to know Node ton of React to get a very fast site out of Gatsby. It it it is I always have the these funny conversations with people where they're like, I just don't understand why you would use a JavaScript framework to build a site and when you could do it in HTML and JavaScript. I'm like, well, you just have you're seeing how fast these these Gatsby sites are? And, honestly, you get so many extra features beyond that HTML doesn't have. Right? You get this ability to change page routes without having a full refresh. Imagine that. Right? So Gatsby just makes some of these things so incredibly easy. I think I could probably spin up a Gatsby site faster and quicker than I could most anything else. So, big big fan of Gatsby. Love these tips. Maybe we should do another one of these sometime.

Yeah. Yeah. Let us know what your tips are to it as at syntax f m. I think that's it for today, and we will catch you on Wednesday.

Peace.

Head on over to syntax.fm for a full archive of all of our shows. And don't forget to subscribe in your podcast player or drop a review if you like this show.