Building Blazing-Fast Websites with Next.js and Sanity.io

So welcome everybody. This is Building Blazing Fast Websites with Next.js and Sanity. Um, so let's get right into it. Just a little intro. My name is Natalia Iaffe. I am a software developer at RangleIO. I'm mostly specialized in the front end. And, uh, most of my work has been with partnering with organizations to like upgrade, um, our technical stacks to react and a lot of projects working, um, with headless architecture and, um, content editing abilities with, uh, with CMS like Sanity, Contentful, et cetera.

Um, yeah. Nancy. Yeah. Hey everyone. My name is Nancy. Um, I also work at Rangle along with Natalia. I am a associate director of digital strategy. Um, but I'm actually just a developer by trade. So I've been doing a lot of headless CMS work in the last year, year to two years. Um, a lot of work with Sanity Contentful. So super excited to be here today to kind of share a lot of our learnings, um, with all of you guys on how we implement headless CMS projects.

Yeah. So, uh, hopefully everybody's seeing my screen. Um, let me know if there's any issues with the zoom guys, but I'll go ahead and chat about, uh, just a little overview of what we're going through today. Um, cause there is quite a bit. Um, so first we'll talk about just kind of what we're building. Um, you have the link that we've sent in the chats to take a look at that right now. Um, we are going to go through the platforms that we're using sanity next for sell, um, as well as storybook, um, and talk a bit about headless architecture and why, um, why use it. Um, we're going to set up the repo. So we'll have a bit of a pause, uh, bathroom break, whatever you've already set up your repo, um, and, uh, give you the scripts to get, to get going. Um, then we're going to dive into sanity. We'll dive into like the pieces that, um, uh, that you need to understand to get set in sanity working. Um, and then we'll have a little pause to set up cause you'll need to get a sanity account and all these things. Um, so we'll have a bit of a pause to set that up and then go into some breakout rooms to configure, uh, to do some activities based off of kind of the set we've talked about, uh, and Nancy and I will be hopping in and out of breakout rooms. Um, so, uh, that should be fun. Um, then we'll go into talking about next JS, which I think some of you have some experience with so far. Some not. Um, we'll talk a bit about that, the site builder, how it powers our app. And we will also go into a little breakout room to like, um, render some of the components that we have in this repo on the page with Next. And then, uh, lastly, we are going to be deploying to production on Vercel. Um, and we'll do some breakout rooms there as well. Um, and then hopefully you'll have a whole working app, um, website that you can customize, um, to your pleasure later. So that's what we'll be kind of going through. And, um, we have some guided times here. Um, but if people are faster, slower, um, we'll kind of work. We'll, we'll see how it goes. Um, so let's chat about, um, what we are building. So, um, just to confirm everyone, Nancy did my screen slide over. Okay, great. So, um, everyone should have this link, but, uh, this is the actual website app that we are building. This is a fictional organization called Pangea, um, for all of your gardening needs. Um, so we're just kind of mirroring an organization website.

This website has, or this organization offers various services. Um, so we'll, you'll have all of the tools to create this full app by the end of this workshop. Um, the other piece of this is the actual sanity CMS authoring experience, which looks a bit like this. We'll dive into it more later. Um, but this is the author experience that we will be building. Have some screenshots and slides for you guys as well, just for reference later.

But let's dive into what is Headless Architecture? Um, if you've, uh, worked with Contentful before, you may know a little bit about this, but if not, um, headless with headless architecture, um, well, you may have heard of, um, various CMS's like, uh, um, WordPress or, um, Squarespace, which are kind of what we call like Headful, where on the platform itself, you build and create components, um, as well as edit content in the same platform. Often they have features that are tied to that platform that you need to use with headless architecture, which is kind of what we're going to be working with. That presentational visual layer is completely decoupled separated from the, um, content layer, meaning like the data, like the different headings you want to use for various components, things like that, um, completely separated. Um, and the data is served, um, to your site via an API from the CMS. So instead of having everything all in one platform, it's separated and just connected with API. So there's two parts of that. Um, we've got the CMS, um, where you manage your data, um, all of your content, images, all of that. Um, something like sanity, which we're using today, or Contentful as some of you might have that some experience with Contentful. And then we have a second part, which is a site builder, um, in our case, it includes, um, using Next.js, but you can use something like Gatsby, if you have some experience with that, um, a component library and page templates. Um, so that site builder will actually end up combining your content from your CMS, um, with your React components, uh, into a really fast, um, Next.js application. Um, so there are some benefits to going headless, um, over having everything all in one platform. First of all, especially, uh, for us, devs, uh, we really love that it is framework, uh, agnostic. So, um, you can be building in the presentation layer or the visuals, um, using any tool of your choice. So, um, if you prefer React, use React, if you prefer Angular, use Angular, Vue, et cetera. So, you can be building all of your components in the language that, um, that you know or that your dev team knows. Um, it's super customizable, um, you can build in, bring in your own components, you're not tied to what, like, a certain platform, you know, like WordPress or whatnot requires of you and you can build in, or you can bring in a bunch of third party libraries for a lot of various features. Um, your, uh, the headless CMS tools are, uh, super optimized for SEO and performance. Um, and like what the app that we're building today, I usually can, um, you leverage, uh, static site generation, which just makes the app super fast. Um, and one of the greatest benefits as well is that, um, since your, uh, data is completely separate from visuals, different platform, that same content can be used across all different kinds of channels and digital touch points like mobile, um, apps, um, VR, maybe in the future, um, and just web applications and websites. Um, because it's all served via API, um, from your, um, from your CMS. So those are some really, um, important benefits of going headless, um, just real quick, sometimes I'm a super visual person person. So, um, visualizing kind of how this journey looks is useful, um, for me. So, uh, in our case, going from the left, you can see our headless CMS circle there is Sandy authors, uh, content editors, marketers will input their content into that CMS platform and the, and the editor interface. And then that API, um, the, uh, CMS API sends that information, um, uh, as Jason to our site builder. In our case, again, we're using next JS. So the site builder gets that data and, um, combines with your component library to build the front end and then a bundle that it bundles that code, uh, and sends it to your distribution platform. In our case, we're going to be using for sale. Um, and in the end, as we know, when we deploy, um, your browser, all it sees is the beautiful HTML with s JS and your, um, really great app that you built. And then zooming in just a bit, um, on the headless, uh, CMS workflow starting on the left. Um, and we'll see this kind of in practice and also do this as well in breakout rooms, but like an author we'll be using the editor interface, um, to create content, published content. And again, all of that content is sent via API or retrieved from the API with as Dayson data to next. So these, um, little info graphics might be just helpful in the future to take a look at just to, um, cause visual they're a little bit more helpful for me at least. Um, so we can just go right into the platforms and tools that we've kind of been mentioning. Um, first I'll talk about sanity, which, um, a couple of you mentioned have not used before, um, is API based headless CMS. Um, you can use the APIs to manipulate, like retrieve and manipulate content. Um, and in our case, we're going to use, um, react to, um, render all of our content into like beautiful components. And then, um, in sanity, something that we really love is that has a native built in preview functionality so that a marketer or something goes into the CMS, they're making a change. Um, you should be able to, to see the change that you're making before going live. Um, and it's really easy to work with sanity, uh, with Next.js. So this is just a little homepage of sanity. You can definitely go ahead and explore if you like. Um, Next.js, um, is I what we're using for our site builder. Um, it's great for static site generation, um, server side rendering and dynamic routing. We'll talk a little bit more about that as well.

Um, and, uh, the great thing about Next.js and, uh, server side or sorry, uh, static site generation is that, um, it creates a really fast app because everything is, um, compiled and bundled at build time. So, um, right when you deploy your application, what somebody sees it has already been built ahead of time. So, it's super performant. That's why we love to use it. And then we'll dive a little bit more into Vercel, but there's, uh, it works really, really great with Next.js because I think they're actually from the same parent company. Um, and, uh, it's got great monitoring tools for performance, um, um, et cetera. So, we'll dive a little bit further into that later.

And then lastly, one of the tools, which hopefully some of you are familiar with. But if not, Storybook is a really great, um, development, uh, environment. It's interactive, which can showcase a component, like your React components that you've built in a completely isolated environment. So, let me actually show you what that looks like. Um, I already am serving localhost, our Storybook here. So, um, you can see here we've got on the left various components that we've already built for this app. We've got Main Hero, for example. We've got Media Module with Image and Text. So, this is a place where all different kinds of people can go and look and play with components and all of the configurable options without having to be in the app. So, you can prototype things really quickly. Et cetera. So, that's Storybook.

Let's get started. Unless anybody has any immediate questions. What we're gonna do right now is set up the repo. We have dropped the links to the repo in Discord and in the Zoom chat. Please let us know if you can't access that or don't see where that is. Maybe somebody, we can just drop that starter repo one more time in the chats. And what we'll do... you can also access it with this deck link. We'll fork the repo and clone that forked version. Run NPM install. And once you've done that, you can run your dev scripts to get these Storybook, the app, and Sanity running. Sanity won't actually be like working entirely yet because we haven't set it up yet. But these are the only scripts that you will need to get everything going. Let's see here. So we dropped the starter repo in the chat. And then why don't we everyone in the Discord just throw a thumbs up when they've got their repo and their scripts going? Let me see. Let me add a little... OK, I just dropped... Sorry go ahead. Oh, I just want to remind everyone to make sure to fork the repo and not just clone it. This is mostly because eventually we want to be able to deploy your version onto Ursel. So forking your own copy onto your own GitHub and then cloning that locally is going to be really critical. OK, Nancy will talk us through after this pause through sanity. So I'll go ahead and switch my share to you, Nancy, now. Yeah, it's totally normal to see a 404 right now for your app because nothing is configured just yet. So as long as your Storybook is running, that's the only thing that should be working right now. We have not yet configured the app or our sanity portal. So that's going to be our next step right after we have the repo ready locally. If you're not early, it'll be really good to take a look at the different components we have in Storybook. We're going to be working specifically with the media module today. We have a couple of, we have all of the components completed today, so you guys won't be needing to create any new components.

But it'll be good to get familiarized with some of the components we'll be working with. I'm going to move on to the next section which will be setting up sanity.

Okay, awesome, looks like everybody's good to go. So in this particular section, we're actually going to be creating the sanity interface. So before we jump into how to actually do all of that, let's just take a quick walkthrough of what the complete sanity interface will actually look like.

So this is our sanity platform. And if, for those of you who are not familiar with sanity, it's actually really customizable what you can actually create using sanity. So all of this, what they call a desk structure over here with our pages folder and global folder, this is all configured by the developer. So you have the choice to create these structures and this interface based off of the needs of your project.

So in our particular case, it's a very simple application that we're building today. So we've only really got our pages folder and global folder. So the global section is already set up for you. And you can see in here, we've just got some of our global elements, like our navigation and our footer, which is not configured per page. It's kind of configured once globally. The second folder we have is the pages folder, which is going to compose of all of the pages and paths within our application. So if we click into this root route, this homepage, you'll see that our page composes of a title, the slug that you can find this page at, and all of the different components and sections of our page.

Like what Natalia mentioned earlier, SanityHacka comes with a built-in preview. So if I hit this preview button, if I do a split screen, I can look at what I'm editing on the left side, and on the right side, I can open up my preview. It's going to take a second to load in, but once it does, you can see the homepage actually rendered out on the right side here. And as I'm editing content on my page over here, you'll be able to see the live update. So this is really great for content authors, because it gives them kind of immediate feedback on what they're actually doing on the page.

But each of these items within our Chef sections is one of these component blocks that you see on the page, they can add additional components onto our page and also rearrange the ordering depending on how they want the layout to look.

Some other things that Sanity also provides for you is a built-in asset management system. So if you head on over to the media section, you'll see that this is where we have all of our images stored. So when I'm actually creating a new component here, I can reference those images those images stored in my media.

The last thing that we're going to be using today, not just yet is this vision tab. So if you head on over to this vision tab, you'll see it's kind of a little sandbox playground to query our content from Sanity. We'll be using this a little later to kind of play around with querying data, specifically using the Grok querying language that Sanity provides.

Awesome. So moving back to actually setting all of this up for ourselves, before we can actually set up our experiences, we have to kind of level set on how we actually build author experiences in the headless CMS space. Usually we typically do this with what they call content modeling, and a content model is usually just a way for us to define and model the interface that we want. So all of the interfaces that we're seeing here with all of our inputs and fields are defined by the developer using insanity, what they call a schema. And we'll get to take a look at exactly what that syntax will look like. But the schema acts as a blueprint to tell sanity how to render a particular content model. And even though content models don't actually have specific types within sanity or content full or any other headless CMS, content models are pretty ubiquitous. They're not defined by pages or page modules. You can use them to model whatever you want. In the context of building a front end application, we like to kind of think of these three types of content models that will help structure our data in a way that makes sense to consume for our front-end application. The first type is the page content model, which will mirror our page structure. So, this is what you're really seeing here. It's usually got two kinds of content. And we'll kind of dive into those. The second type is the page module, which tends to mirror your components. And the last type, which we're not going to be working with too much today, is the data object, which tends to mirror miscellaneous data that aren't usually presentational. So, things like your SEO data or your settings, typically you want to just return those and utilize those in the form of a JSON object, this is a really great way to capture any other content.

So, diving a little bit deeper into our page content model, so the page content model, like I mentioned before, actually mirrors the information we need to create a page. So, the two types of content we typically see in here are either metadata, which are things like our title or meta description or our slug. So, nothing very visual. And the second one is going to be capturing our page layout, so this is our sections area over here, which is going to determine the kind of component that we want to render, the content that's going to be rendered on the page, and also the order in which these components are going to render.

The second type, the page module, is going to be mirroring a single component. So, on the right here, you're seeing the CTA banner, which is one of the components in our component library and also available in the CMS. This kind of content model mirrors all of the content pieces an author can enter in to configure a component. So, how do we actually go about creating these content models? Like I mentioned earlier, Sanity has a very specific syntax when it comes to creating a schema that defines a content model. This is the syntax you're seeing on the right-hand side over here. For the most part, it's pretty much a JSON object with very specific fields that you have to fill out in order to tell Sanity what you're actually wanting to render. So in here, we've got the schema name at the very top here. This is you can almost think of as the equivalent of an ID for the content model. We've got our title over here, which is what is actually going to be displayed in the Sanity interface. So coming back to our example here, we've got our CTA banner. The title is actually what's physically rendered in the UI. So this is typically more user readable, just so it's a friendlier experience for your content authors. Then we've got a list of the different fields, which is actually what helps render all of the different sections of fields that we see in our UI over here. One thing to note here is that you'll see us use the define field and define type function. This is actually optional, but it does help provide some type checks for all of the shape of the object that you're passing in. So for example, if you forget to add the type or the name, it'll just provide you with type errors to help guide you along. But if you don't want to add in the boilerplate, you can also discard all of the functions and it will just be kind of a flat object structure that you're familiar with. So last thing I want you guys to know on the schema is the type over here. So you can kind of see here that we've got the type set as an object and there's a couple of different types of schemas that we can have in Sanity. The two that we're going to be really working with on a schema level is the document and the object schema and that's going to help us define either the page or the page module content types that we were just talking about. So when it comes to documents you can think of them as a parent schema type. All of the other types of schemas that we're going to be creating including the object is going to live within the very similar to what we were looking at earlier. This page will be considered a document type and you can see all of these individual components which are object type are going to live within the page itself. Interesting to note here is that documents are the only ones that can be queried when it comes to actually fetching your data. So things like pages are things that we want to be able to fetch all of the pages, so it needs to be a document type. So when we're modeling for a website, the document again is usually what creates the page content model that we're seeing versus the object. This is usually used to define custom types of fields, numbers, arrays and this is not queryable. So, although this can live within a document you can specifically query for example all of our CTA banners. And we do use this to model all of our components and the page module content models that we were just talking about.

I know that's going to be kind of a difficult topic to grasp. Any questions right now from anybody on what we talked about so far with content modeling?

Okay, I'm going to move on but there will be opportunities. Oh yes, please. Okay. So, what happens when you want to fetch some content from only an object? You have to create another page for it? Exactly. So, it's really important to kind of think about how you want to use your content. So, if you know that the content needs to be queryable, then you want to make it a document type. So, for example, here we know for a fact that our pages, we need to be able to query all of our pages. In that case, this needs to be a document type. The CTA banner only simply lives within the page. We don't need to query all of the CTA banners across our pages. So, this could be an object type. Using similar kind of logic here with our navigation, we need to be able to query the navigation and the footer individually to render our top navigation and footer. So, in this case, these all need to be document types. Or we won't be able to fetch the data for those. All right. So, diving a little bit deeper to look at how we actually define each of the fields.

So, the fields are primarily determined by the field type that you enter. So, sanity provides a bunch of different types that you can have. And depending on the types, it will render either text inputs or toggles or even image selectors. Additional things you can actually configure per field is things like field validation or initial values. And those are just going to be really helpful for creating a friendly user interface to provide more guidance for your content authors when they're entering content.

I'm just sharing here the schema documentation if you guys want to take a look at all the schema types that are available. I'll have this link up again when we get on to the hands-on portion where you'll need to dive in a little bit into the documentation and figure out how to actually create a field. But breaking down the field a little bit further just to look at what each of these properties actually render out.

We've got our property right here that's set to boolean, which will render our toggle input provided by Sanity. We've got our title again over here. Similar to on our schema level, you'll see that it's just used to display this user-friendly label on the Sanity interface. Looking at a second example, we've got our string type over here, which instead of a boolean, it renders a text input, and with our validation added in, you'll see that if the user has left this field empty, Sanity will provide this nice little error message just to indicate that this field is required. The last thing to know here when you're actually creating your own schema is that naming for all of our schemas and fields are very, very important, and we'll get to revisit this a little bit more in the next JS section as to why we are very... it's very critical to actually match the name of your fields to the property names and the name of your schema to the name of your component. But for now, just kind of remember that we need to do this when we're creating schemas. Do remember that it is case sensitive, so if you have camel case over here for your props, you need to make sure that both of these are the same casing and the same spelling. So at this point, I'm going to hand this over to Natalia, who's going to just go through a real example using the CTA banner in our component and walking through the end-to-end process of putting together a schema in Sanity.

Awesome, thank you, Nancy. So let me just share my screen here. 2023, post COVID, still trying to figure out how to share screens gracefully. Never gonna happen for me, guys. Okay, hopefully you're seeing my entire desktop. Yes. Okay, awesome. So what we're gonna do right now, so we learned a bit about some abstract concepts kind of about content modeling and all of that, what we're gonna do right now is just try to make that a little bit more concrete with like the project that we're working on right now. So taking a look at like the homepage of our project, we have this CTA banner image, heading with CTA. So let's dive in to the codebase and see how we build a schema for that. So first, hopefully you guys are looking at some code right now. First we'll take a look, thank you for confirming. We'll take a look at our components file in our or the folder here and we'll take a look at CTA banner. So if y'all are React developers, y'all are very familiar with a component like this. A presentational component that just accepts props and renders them. So we've got the CTA banner that accepts these props, we've got a heading, image and the alt text for the image and a CTA. So what Nancy was saying about creating a schema where various names are matching with your component is really important. So we'll just notice that these are the names of our props and CTA banner is the name of our component. So I'm going to scroll down in this file structure down to the sanity folder and open up our schemas, which is where we're putting all of our schemas. So Nancy mentioned that there's objects and documents, document being something like a page is here, and then we've got open up our objects which mirror our, what Nancy was mentioning is a page module or components. So I'm going to open up CTA banner here. So this is the schema for the CTA banner and we'll notice first off that the name of our CTA banner matches the name of our component. Very important. And we'll, once we dive into the site builder section, we'll kind of show you why. And again, case sensitive. And then we'll also notice that the title is CTA banner. So, when we actually dive into sanity, we'll actually notice that when you drop an actual, like, when an author goes in and creates a CTA banner, the name of it is here. When you edit it, it says, edit CTA banner. That's all created from the title here. Then we take a look at the fields of the CTA banner. We'll notice that these mirror the props that the CTA banner requires. We've got our heading. We've got a CTA. We've got an image. The heading is a string type. The image is an image type. It's a sanity image type. Now, if we take a look at the CTA, the type of CTA, now, this is not an out-of-the-box sanity type. This is us referencing another schema that we've already built. So, if you have another, like, we have another object here called CTA, which we want maybe other modules to be able to include a CTA. Take a look at that object. It has a couple Boolean fields and a couple string fields. The name of it is CTA, and that's how we reference it here. And then, if we take a look at that schema again, if we open up, later, you'll have all this kind of to look through. But if we open up the CTA banner, we mention that building these schemas, these content models, all of that is to create the, like, the Lego blocks of building our authoring experience in the sanity interface. So, that's exactly what we've done. We've said that the CTA has two Boolean fields. It looks like this. Has two string fields. Looks like this.

Heading and image. So, we've built that all with our schemas. We also have down here, we won't dive too deep into this piece, but this is a pretty customizable piece of a schema called the preview. And you'll notice here that we're selecting a couple of the props, heading and image, and we're preparing it. So, what that directly mirrors is the experience of seeing that you've dropped a CTA banner on this page, and you have the heading, you have the name of the component, and the image. So, the preview directly mirrors what you actually see in this list when you build, when you drop a CTA banner onto the page.

The last piece after you've kind of built your schema with your fields is that you want to scroll down to the very bottom of this file structure, and you will see a sanity.config.ts. So, this is our sanity configuration, you guessed it from the name. Up at the top, we've got a bunch of imports, including on line 25, a CTA banner from our schemas objects folder. So, we're importing this into sanity config, and then including this CTA banner in our configuration object for our schemas here. Super important to make sure to add that to the schemas object or else sanity will have no idea that your CTA banner exists. You built the schema. You can't use it. So, adding it here to this section makes the schema available to use.

Now that you have your page schema set up and we've got a couple of pages built out. It's time to kind of take a look at how we actually can go about querying our content. So, sanity actually provides you a couple of nifty little tools to do this. So one of which is just to get a sense of what the shape of the data actually looks like. You can go into this three dots section and click inspect. So, this will actually show you what this page data will look like. You can kind of see that we've got our type. We've got all of our sections and our components in here with our type equaling the name that we've given to the schema and all of our different components, the properties and inputs that we created, the fields with the name that we've chosen. So, the background image, the body, and all of the different sections in here. So, in order for us to query this content, we're actually going to be using Grok to do that. So, for those of you who've never used Sanity before, Grok is actually Sanity's open-source query language. It's very similar to GraphQL, but I would say that it's actually even more flexible and powerful when it comes to being able to query data to the shape that you actually want. So, we can actually test out all of our Grok queries within the Sanity studio. So, if you head on to the vision section that I showed earlier, we're able to put in our query in here and test out what our Grok query actually returns.

So, in order for us to query this content, we're actually going to be using Grok to do that. So, for those of you who've never used Sanity before, Grok is actually Sanity's open-source query language. It's very similar to GraphQL, but I would say that it's actually even more flexible and powerful when it comes to being able to query data to the shape that you actually want. So, we can actually test out all of our Grok queries within the Sanity studio. So, if you head on to the vision section that I showed earlier, we're able to put in our query in here and test out what our Grok query actually returns. So, I shared here just the link to the query cheat sheets. When you click in there, you'll see that there are so many different things you can do with your Grok queries to be able to sort, filter, and quite a lot of different complex calculations. But all we're going to be utilizing today is actually quite simple. So, just taking a look at the anatomy of a Grok query, what we have here is just the syntax we're going to be using to select all of the documents. And within the square brackets here is how we're going to filter what kind of documents we want to select. So, here I just want to select all of the documents that have the page type. So, that's all of the pages that we've created. And then within the square brackets or within those squiggly brackets in here, very similar to GraphQL for those of you who are familiar, we can actually dictate the shape of the content or the shape of what we want to actually fetch back. So, even though if we look back at all of the data that exists on our page, you see that we actually shown this inspector before. Like how to get here. Yeah, it's just yeah. Yeah. So, in this section over here, we can see that there's so much different metadata in here, including one of the fields that we have at the bottom, which is our slug. So, what we can do here is instead of returning the entire object, we can actually choose to just return the slug field within this page object. And what we can also do is actually change the shape of it. So, even though this is a slug object containing the type and the URL, if we just want to simplify the structure of this to just return our URL as, like, a flat string, we can do that by assigning slug.current to our slug type. Alternatively, we look at the second example. You can see that we can actually add additional filters here. So, not only are we selecting the page type, we can actually also select a specific page. So, here I'm just selecting a page type that has the slug at our home page. In here, if we're not interested to select and manipulate the shape of our data, in our case, oftentimes, we just want to return all the data that the content author has inputted. We're just going to use the dot, dot, dot notation, which will return all of the values inside your document. So, it will return everything that you're kind of seeing in here. So, we're going to move along here pretty quickly, but if you want to take a look at what this actually looks like, you can pop into Vision. In here, for example, if I'm just selecting this particular query, I can run this, and immediately we're able to see the page that I've created that's on the home page and all of the contents in here. Similarly, if we did just our slug, you'll see here that we're only now just returning the slug field.

All right. So, we're going to hop on to the Next.js part to finally connect all of the content that we just created in our Sanity platform into our Next.js repository. So, before I jump into that, I'm just going to quickly show you guys where in the code base we're going to primarily be looking at.

So, we're looking at the code base here. We've got our pages folder. This is really primarily where all of our page layouts and routing is going to be located. So, Next.js does utilize a file based routing structure which means that the folder, how we name them, and all of the file and folder structure is actually what determines your routing within your Next.js app. It's a little bit different in React where you don't actually have to configure anything manually. It's all about how you structure and name your files and folder.

You immediately see this weird folder name. We'll get into that a little bit later, but this is actually where, this is the template that we're going to be using to create every single one of our pages within Next.js. And it is a dynamic, this is a syntax for a dynamic route. So, with this one template, we're going to be able to generate all of our routes. You're going to see some other routes in here that you're not really going to be touching at all, we've got this API route, which basically helps us generate our sanity preview. We have a studio path. This is our integrated sanity studio. So, this is why when you navigate to slash studio, you're able to access sanity because we've got all of our sanity content under the studio route. Some other things to take note of is this app TSX. So, this is one of the next JS files that we use to create anything that's sort of global for every single template. So, in here, we usually have things like SEO. We've got things like our navigation and footer. And anything that's placed in the app TSX is automatically going to be rendered on every single one of our routes. What's really nice about this is now you don't have to add in the navigation and footer and all of those global elements to every single one of your templates. If you put it here, it's just going to show up everywhere. The last area that we're really going to be touching today is the utils folder. So, inside the utils folder, you'll see a singular build component utility function. This is actually going to be our page builder, and we're going to run through what all of this code is doing. But this is what's going to help convert all of our JSON data from sanity into React components that we can actually render on the page. So, jumping back into our routing. So, like I mentioned, Next.js has a file system based router. So, when you're adding new files and folders into the pages directory, it's automatically available as a route in your application. When we're dealing with dynamic routes, however, you can't just hard code the file name. So, the syntax to actually accomplish dynamic routes is with your square bracket and your file name inside of it. This is a singular dynamic route segment. So, what that means is that it will allow you to create like a slash services route because it's a singular URL segment, but it does not let you create something like a nested path like slash services slash garden design because now there are two file segments. Example that will look like is using slug as our variable. We've got our square bracket, slug.tsx. So, it doesn't quite look like what we've got going on here just yet. And in order for us to actually capture all of the slugs, we need to do a little bit more. So, in order for us to actually capture all of the slug segments, we're going to have to extend it to a catch-all segment. And we can do that by adding the ellipsis in here. So, all of a sudden, it's not just going to work with services. It's also going to work for services slash garden design or however many URL segments you want to tag along into it. A really important thing to note here is it's actually not going to capture the root homepage route because it only works if you have path segments. So, in order for us to capture the home route, which is the last kind of route that we'll need to create our application, we want to make it a optional catch-all segment. And we do this by adding the last square bracket around here, which this is the actual file name that we're actually seeing with our page template in our code base. So, you may be wondering, okay, what does that actually mean? Catch-all versus optional catch-all? So, with a catch-all, we're only able to catch routes that have segments. So, here we've got shop slash A slash AB and slash AB and C, so, these are all going to be available to be created with the catch-all route. But it is not going to be able to create a route route that doesn't have any subpaths to it. When we do make it an optional catch-all, we all of a sudden allow the route route to be created without any subslugs in it.

When we actually go in and want to create a dynamic route, we need to actually define a list of paths to be statically generated by Next.js. We can do this by utilizing a built-in function that Next.js already has called Get Static Paths. This function is expecting you to return a list of parameters with your slug segment. You can see here if I want to create the about us path, it's just about us. If I'm looking to create something like services slash garden design, because it's two segments, we actually have an array of both of those slug segments within. This is kind of what it will look like in terms of the structure that Next.js is expecting us to return, but oftentimes, we'll not be hard coding this because these are dynamic routes that we actually want to create based off of the contents that a content author entered in Sanity. We'll actually be fetching all of the page path information from Sanity directly and mapping it to the structure that we're expecting. So in order to do that, we need to actually query data from Sanity. So to query data in Sanity, not only do we have to have the PREQ rock queries, which is kind of what we worked on previously, we also need to have some sort of way to be able to fetch that data specifically in Next. So to do that, we're using a helper library called next Sanity, which has this really nifty live function called create client. So this kind of asks, as the SDK, we will need to provide it with our project ID or data set, which has all been already configured in your EMV local. So all of these informations, we're going to be passing into the create client to make our connection to the sanity API. Once we've got that going on, we're able to then create our function to actually fetch our Grok query. So here you can see we are calling the sanity client. We're going to be fetching a query that we have created to get all of the page paths. Similarly, once we've created all the paths, we will need to then fetch all of the page content for every single path. Because all of this is dynamic, we're going to be using something called get static props, which is another built-in Next.js function to pre-render the page with all of the props that we'll need to create this page.

So on the right here, you'll see an example of a get static props from the code base. The context here is going to give you back the URL that you're actually on. So the params.slug is the current component that is being built. From there you can use that information to fetch the correct page data from Sanity. So you will see here that I'm fetching a couple of different things from Sanity. I'm fetching the page data, I'm fetching the navigation data, and the footer data. So with all of these different data, fetched and ready to be used, I'm able to then return it from the GetStaticProps and make this available to be used inside of our React component. So here I'm returning a global object with the navigation and footer and also our page data. A really interesting thing to note here is that anything that's kind of returned from the GetStaticProps will be available to be accessed in that underscore app file. So things like our navigation and footer, if we're fetching this content in our page, we're able to access all this information and be able to render the navigation and footer using the data fetched here for every single page. So similarly to what we did with the path, we will be fetching all of this data from Sanity to be displayed. So none of this is going to be hard coded.

So now that we have all of our JSON data, just remembering what that kind of looks like, this is kind of the shape that Sanity sends back to us, we have access to all of this inside our component. It is time to actually convert this JSON into React components. And we typically do this utilizing a function called build component. So remembering back to what we had in our utils folder, this is where the magic happens, where the JSON will be converted to something we can actually render on the frontend.

So let's take a quick look at what the build component function is actually doing. So the first thing it's going to do is create this component mapper. Thinking back to why we were very adamant about naming the component a certain way, this is really the schema a certain way is because this is where it needs to match. So your schema name, if you look at the JSON that gets returned, you'll see that the type is going to be your schema name. We really want to be able to match the schema name to the actual component name in our component mapper. So here we're going to import all of our CMS modules, make it available in the components map. And then as we get into the build component function, you'll see that it's doing a couple of things. We've got a couple of null checks going on just to make sure that the data has the underscore type. If it does have the underscore type, we want to go ahead and select that component from our component map. So by this point we should have a valid component here. But if for whatever reason we forgot to import one of our CMS components in here or if we accidentally named things incorrectly, we will just want to throw an error. The components here will be undefined. It will not be able to select a valid component. We just want to throw an error to just say that no component has been registered. But if everything goes well, we should be able to return our selected components. And from what you're noting here, aside from the type that's being used to select the component, all of the other properties within our JSON is going to be used as props. So again, why it's really important for us to be matching the name of the fields to the property within the component. This is where it's coming in. If for a reason you didn't match the name, then your component won't be able to receive the proper content from Sanity because the names will not match up here.

All right, so that was quite a lot of information. But hopefully all of this will make a little bit more sense once you get into the code base and start connecting things on your own. So just to get a sense of what we'll be working with today, the first thing we're going to be doing is heading into our Slug template. This is where we're going to be first. Taking the path, so we've already got some queries here set up. We're already fetching all the data from Sanity. We're just going to be taking the path and making sure we're mapping it to the shape that Next.js is expecting. If you got some bonus time, feel free to try writing your own rock queries to be able to query the page path and also the page content. If you don't have any time, that's okay. We've got it already written here. The next thing we want to do is head to the build component and make sure we're importing all of the modules that we need into our components map. Once we have all that ready, we're able to head on to line 37 where we've got our page component. It's currently empty, which is why you don't see anything rendered on the page. We want to use our build component, map through all of our sections, and generate all of our React components so that everything will be displayed on the page. Awesome. Any questions? We're ready to jump in.

Yeah. Do we want to do like a full 20? Do we want to do a 10 and then do it together? Yeah, we'll have to, yeah we'll probably timebox this a little bit more so that we can get to the deployment section. So we'll probably do maybe 10-15 minutes to get people to try some stuff on their own. And then we'll finish the rest together. Okay, cool. I'm going to walk through what we'll need to do to kind of get through setting up the page template as well as rendering our components. So kind of following some of the to-dos that we have on the page. The first thing we'll need to do is head into our Get Static Paths. So within here we've already got the paths kind of coming from Sanity. What we need to do is actually map those paths to the shape that we're looking for. So just to remind everybody, this is the shape that Next.js is expecting us to create.

And we just want to go ahead and actually map through the Sanity data so that we are creating, what we're returning is a list of params object with our slugs. The gotcha here is really remembering that the segments needs to be separate array items in here. So we're just going to be doing a split in here so that we're able to create the individual segments for the routes that require multi segmented paths.

The second thing that we're going to be doing is actually hopping into our build components. So within our build components, we're just going to be importing all of the components that we're going to be using in the CMS, the CTA, featured items, all of that from our components folder, and then we're going to be plugging it into our components map. So once we do that, all of those components are ready to be synced up with the schemas that we created in sanity. You shouldn't need to actually do any configuration to the build components function. Everything should just work once you've imported in all of the components.

Once all that is done, we can actually head on over to our page template again, and in here, we've already have everything set up in the guest static props. So we're already fetching our page content, navigation, and footer data, and we are returning it in the props here. So we should be able to access it within our within our template here. So we've got our page props, and you'll see we've got our pages here. So in here, what we need to do is we know that everything that's UI-related that we'll need to render is in the sections array. So what we want to do is map through every single object within our sections and build out our component using the build component function and passing the section data or component data to it. And what we should be getting in the end is our fully complete app where depending on what you've inputted into your own CMS, you should be able to see those components rendered out. So for us we have quite a few components on here rendered and we should be able to see all of those content displayed.

Well, do you have any questions? Well, this is a big information of hopefully, hopefully you can refer back to this recording as well when you're creating your own projects to get things going. Yeah, this might be something you kind of take a look a little bit closer after the workshop. There is a lot of different moving pieces here. It'll be definitely kind of interesting to see if you can create your own rock queries for some of these areas that needs querying data. Yeah, awesome. In the meantime, we're going to move on to our last section. So hopefully by this point, we have all of our pages rendering for each of our paths. What we want to do at this point is be able to deploy it to production through Vercel. Nance, do you want to take over? Sure, if you want to do the same. Okay, let's give you a rest. Okay, so we are going to go through what it is like to deploy to production. And previously, we talked about using the tool Vercel for this so that we can get all of our code from Next.js and have that showing up on a browser. So there are a number of steps. So we'll have you kind of do that on your own after this, or we can do it together. But the steps, first of all, obviously, you need to get a Vercel account, we always sign up with our GitHub. It's best to connect with GitHub. And this is like a free hobby account. Vercel has different paid accounts, but this is just for fun. So go with the hobby account. And in Vercel, there's a way to create a new project. And in that new project, you import this GitHub repo that you're working on. If you didn't sign up through GitHub, you'll need to I think connect GitHub to Vercel. So that's why we definitely recommend just signing up with GitHub. And then you'll need to set up some environment variables first so that Vercel has everything it needs to actually understand the product ID and all the different things that connect it to sanity and deploy it. So don't deploy yet. So setting up those environment variables, you guys all have that in your environment.local right now. So you'll just want to paste those all into your Vercel's project environment variables section. You can paste them one by one and add them each or you can just paste the entire file right in this area here. And then once those have been added, then you can hit deploy. So we don't want the website just be static and never change. So we want to set up, like theoretically, if you're building an organization's website or something like that, you know, somebody is going into Sanity and authoring new things and updating the pages, you want to set up a webhook so that Vercell can rebuild every time an author publishes in Sanity. So let's say you change the name of the site from Pangea to, you know, Marianas great website, you want to publish that in Sanity and you want Vercell to pick that up. So you'll create a deploy hook in Vercel. We just have some instructions here where to find that within the settings.

And just give it any name and set the trigger to main. And they will generate for you a URL for you to use. So make sure to copy that URL and then go into sanity and make sure you complete that connection.

There is over on the sanity side, there is an API section with web hooks. And you want to paste that URL that you got from Vercell into their web hook section to complete that connection. So now Vercell and sanity are working together. And just some gotchas here. Make sure you select the triggers create, update, and delete and save.

So definitely use those instructions here to just follow and get this connected to Vercell. And I don't know. I guess we can give you some time to do that. And once things are deployed, if you make updates to your site and make updates with Insanity, you'll be able to see those changes happen on the live URL that you get. So, yeah. The result of this, you'll have a deployed link for your project and see your updates.

What do we think? I guess we'll stay in here if anybody has any questions as you do that. It would be great to see anybody's like cool custom stuff that they've built. After this, we'll just say customize your website, drop whatever images you want, drop whatever color palette you want, you know, change some of the text that you see and create something kind of custom for you. So yeah, for now we'll just get all the Vercell stuff set up and let us know if you have any questions about connecting Vercell with Sandy, getting those environment variables in, any of that. So we'll take, I don't know, five, ten minutes for that.

Yeah, we have technically two more minutes left in the workshop. If people have any general questions that they have not necessarily just about the activities for any of the content that we kind of presented today, I'm happy to take questions if you just want some more time to kind of work through some of the deployment stuff, we'll stick around. If there's anything that you have questions about or you run into any issues. But this is kind of the end of the workshop, so hopefully everybody learned something and they're able to kind of have their own website deployed at the end of it.

Good on you for checking time I would have just kept going and going and going. In case anyone has to leave, this is kind of the last steps that we'll need to complete. Does anybody have final questions, any thoughts, any like errors that you immediately ran into, or anywhere previously that you got caught up and couldn't continue, even if it's just sanity stuff or Next.js paths stuff. We're happy to answer those questions now as well.

Okay, if not, then we really appreciate you guys joining us and getting through all of that information. It was a ton. Once you get used to building sites like this, it goes really, really quickly. And the good thing now with this repo is you've got some really nice boilerplate to kind of go from here. And there's so many different kinds of ways to configure sanity and the authoring experience. There's a lot of different ways to query data and use the builder. So definitely have fun with it. And yeah, you get some nice boilerplates to go off of. So yeah, thank you guys for joining us. We'll see you next time, I guess. Thank you, Nancy. Thank you, everybody. Thanks, everyone. We'll stick around for like another 10 minutes in case there's last-minute questions or anything like that.