Next.js is a minimalistic framework for server-rendered React applications.

Maxime Bourgeois

Next.js is React’s recommendation for building server side rendered (SSR) web apps. It features SSR and Static Site Generation (SSG), TypeScript support, routing, and more. 

In this lesson you will also set up this course’s example and learn to create a new Next.js and TypeScript project.

Create a New Next.js and TypeScript Project

You will get a tour of the default Next.js project structure. 

You will also learn how Next.js uses the files and folders within the `pages` directory to generate its routes, and that each route is simply a React component. Navigation between these routes can easily be set up using the `Link` component from `next/link`.

Create New Pages in Next.js and Navigate Them Using Link

Next.js dynamic routes are both powerful and ergonomic. Simply wrap the filename for your dynamic route in square brackets `[]` and Next.js will interpret that route as dynamic. 

Once you have a dynamic route you can use Next.js’ `useRouter` hook to access URL parameters and use them in your component.

Create Dynamic Routes with Next.js

In Next.js, static assets can be added to a project by creating a public folder in the root of the project and placing the assets within. 

Serve Static Assets in a Next.js Project

The image component from Next.js comes with excellent performance optimizations that make it worth using. It comes with improved performance, better visual stability, faster page loads, and more!

In this lesson you’ll learn how to use this component to serve both local and remote images in your Next.js app.

Serve Optimized Images Using the Next.js Image Component

The `Head` component in Next.js functions similarly to its native HTML counterpart. 

You can use it in your page components to provide page-specific metadata such as title, description, viewport etc.

Provide page-specific Metadata Using the Head Component

You can override the default App component in Next.js by creating a `_app.tsx` file and defining your own `App` component. By doing this, you can use global styles, pass custom props, and more.

Override the Default App Component in Next.js

The Document is like the top level HTML structure of your Next.js application. By default it looks like this: 

```jsx
import { Html, Head, Main, NextScript } from 'next/document'

export default function Document() {
  return (
    <Html>
      <Head />
      <body>
        <Main />
        <NextScript />
      </body>
    </Html>
  )
}
```

As you can see it looks pretty close to an HTML document but with custom components instead of the native tags. Here, you can introduce custom behavior like fonts, scripts, icons, etc.

Override the Default Next.js Document

There is a plethora of options when it comes to styling your Next.js app. Global CSS, component level CSS, CSS-in-JS, or some kind of CSS framework. In this lesson, we are going to be focusing on the first three.

Creating a global CSS file is as simple as create a file called `global.css` under the root `styles` directory and importing it into your `App` component. 

CSS on the component level is accomplished using CSS modules. To do this you can create a CSS file on the same level as the component and give it the same filename but the `.module.css` extension instead of `.tsx`. Then you can import this into your component and use it as `styles`.

CSS-in-JS is done by using a `style` prop inline in your TSX and defining CSS with the object + camelCase syntax.

Style Your Next.js App with Global CSS, CSS Modules, and CSS-In-JS

There are two main types of custom layouts you’ll find in many applications: Single Shared Layout and Per-Page Layout

The Single Shared Layout is a layout that you want every page of your application to share. This is so that components like your `NavBar` and `Footer` don’t have to be defined on every page that you build. We will accomplish this type of layout by creating a Layout component that will wrap our application in `_app.js`. Because `_app.js` is the root of the application and renders every page, our layout component will also get rendered on every page.

The Per-Page Layout lets you be a lot more fine grain about what pages receive what layout. If you have a big website and need to apply different layouts to different pages (auth, dashboard, settings, etc.) you will want to consider using this pattern. To achieve this pattern, we will define a `getLayout` function on the pages we want to receive a custom layout and in `_app.js` use that function to wrap the page in the layout with a default of rendering the page as is if the function is not defined.

Create Custom Layouts in Next.js to Apply to All or Individual Pages

A common pattern that is used in development is to use a UI framework to handle styling for the components that you build. This super charges your feature development and can allow you to iterate faster at a higher quality. 

For many of these frameworks, you will need to do some set up.  This lesson takes you through the set up of Chakra UI in Next.js. You’ll find that you will need to adjust your _app and document files to get started with UI frameworks in Next.js. In this lesson, we will get Chakra set up as well as provide our app with an initial color scheme.

Super Charge your Next.js Development with UI Frameworks like Chakra UI

There are three main ways that you can render in a Next.js application: pre-render with server-side rendering (SSR), pre-render with static site generation (SSG), or updating/creating content at runtime with incremental static regeneration (ISR).

This lesson dives into the theory of these three methods before jumping in to the implementation of these methods in Next.js. You’ll learn the benefits and constraints of each method. For implementation of these methods, check out: **[Statically Generate Pages through SSG and ISR with Next.js getStaticProps](https://egghead.io/lessons/typescript-statically-generate-pages-using-ssg-and-isr-with-next-js-getstaticprops-and-getstaticpaths)** or **[Dynamically Generate Next.js Pages with Server Side Rendering using getServerSideProps](https://egghead.io/lessons/typescript-dynamically-generate-next-js-pages-with-server-side-rendering-using-getserversideprops)** (the next two lessons!).

Understand SSG, ISR, and SSR Rendering Methods used in Next.js

‘Static generation’ (SSG) generates data at build time or when we run npm run build. It will generat all of the HTML files for us, which we then served statically. This makes our website fast for the users that visit it. 

In Next.js, SSG is achieved through a `getStaticProps` function. This function can be exported from any page in Next.js and will fetch and build data for that page at build time. Next.js Strips this method from the bundle so it’s safe to use database connections and API secrets inside of.

You will often need to generate dynamic pages in combination with `getStaticProps`. To do this you will need to also export a function `getStaticPaths` that tell Next.js what pages to generate.

After you learn the `getStaticProps` api and what SSG looks like when you build, we’ll add set `revalidate` to an interval inside of `getStaticProps` which will let us tap into Next.js’ Incremental Static Regeneration feature. This will have the server rebuild the data at a set interval so our site can update for new users.

Statically Generate Pages using SSG and ISR with Next.js getStaticProps and getStaticPaths

Server Side Rendering (SSR) will render each page on every request of the user. This means that the server is waiting for the user to request a page before generating the html that will be displayed to that user. This rendering method is great for dynamic data or data that changes often but comes at a cost. Your pages will generate slower than if they we’re using Static Site Generation (SSG).

To user SSR, you’ll just swap out `getStaticProps` to `getServerSideProps` on your pages you want to use SSR with. Next.js handles how it renders for you. When you switch these functions out, you’ll also have access to the client query and request as well as the server response. These are great for checking for any cookies or auth that you might need to.

Dynamically Generate Next.js Pages with Server Side Rendering using getServerSideProps

Next.js is built on top of Node.js which means that you can define functions that will only run on the server. These functions are called API routes. 

These API routes allow you to interact with 3rd party services, connect to the database, or use environment secrets without exposing any of that to the client. In short, they let you build out an API all inside of Next.js.

In this lesson, you’ll see how to fetch user data by id and return that data from an API route. You’ll learn about handling requests sent to the API route and what type of responses to send back to the client.

Define and Use Next.js API Routes to Make Server Side Requests

Next.js can be deployed anywhere but an easy way to deploy is through Vercel, the creators of Next.js.

Vercel lets you use any rendering method on your pages right out of the box and lets you take advantage of their edge network that keeps your app blazingly fast.

You can follow along to deploy your own app at [nikolovlazar/deploy-nextjs-on-vercel](https://github.com/nikolovlazar/deploy-nextjs-on-vercel)

Deploy your Next.js app on Vercel

With this course, you will understand how to call handle different HTTP verbs  in Next.js API Routes as well as learn how Next.js is a viable option to create RESTful APIs.

Effectively Build RESTful APIs using Next.js API Routes

Colby is going to take you on a deep dive into creating a full featured store for your business.

ECommerce Product Management & Storefront with GraphCMS, Snipcart, & Next.js

Learn to model real-world scenarios in actual relational databases, understand how to manage real-time data, and leverage key functionality provided by Supabase.

Build a Real-Time Data Syncing Chat Application with Supabase and Next.js

The Beginner's Guide to React

Fundamental Next.js API and Patterns

https://app.egghead.io/api/v1/lessons/typescript-create-a-new-next-js-and-typescript-project/subtitles

Instructor: [0:01] Let's begin by learning what Next.js is. Next.js is an open-source React framework built on top of Node.js. It enables developers to build super fast, optimized websites and web apps.

[0:12] While traditional React apps are rendered on the client side, Next.js gives you the option to also render your pages on the server side. Its features like the built-in router, per-page rendering options, incremental static regeneration, TypeScript support, etc., provide the best-in-class developer experience and rapid feature development.

[0:33] The React documentation lists Next.js as the recommended tool chain for building server-side-rendered web apps. It is originally built by Guillermo Rauch and is developed and maintained by Vercel. That's a small intro to what Next.js is.

[0:49] To begin with this course, go ahead and clone this repo. This is a mono repo that contains all 15 lessons that we're going to go through in this course. Feel free to pause this video and clone the repo.

[1:04] After you've cloned this repo, open it up in Visual Studio Code. The first thing we need to do is run npm install at the root of the project. This will install all of the packages and dependencies for this course.

[1:16] Throughout this course, we'll be working in the Exercises folder. As the first exercise, we are going to create a new Next.js TypeScript project. Let's see into the Exercises folder and enter the first exercise. To create a new Next.js TypeScript project, we need to run npx create-next app. We'll provide a name for our app. Let's call it Hello Next.js.

[1:45] Then we will pass the TypeScript flag. Just hit y on this step, and there we go. This command will create our Next.js TypeScript project called Hello Next.js. If we cd into it and execute npm run dev, it will start our development server. We can visit localhost:3000, and we're going to see the new project page.

[2:13] That's about it. To recap, we learned what Next.js is, some facts and history about Next.js, and we've created a new Next.js TypeScript project.

https://app.egghead.io/api/v1/lessons/typescript-create-a-new-next-js-and-typescript-project/transcript

https://app.egghead.io/api/v1/lessons/typescript-create-new-pages-in-next-js-and-navigate-them-using-link/subtitles

Lazar Nikolov: [0:00] In the previous lesson, we learned what Next.js is and how to create an empty Next.js project. In this lesson, we're going to learn how to create pages and build the navigation. Let's open exercise number 2. This is the default file structure for every Next.js project. Let's go through it.

[0:19] We have the .Next folder, the Node_modules, the Pages directory, the ESLint configuration, gitignore, the Next environment typings, package.json, README, and TypeScriptConfig. If we open the Pages directory, we will see the index.tsx. This is basically the home page.

[0:38] In Next.js, every page is a React component that lives inside of the Pages directory. Every other React component that lives outside of the Pages directory is not being considered as a page. That's how the built-in router can generate our routes automatically.

[0:52] For example, the index.tsx file is being mapped to the home page or the /route. If we were to create an about.tsx file, that would be mapped out to the /about route. Let's try that. Let's do right click on the Pages directory, new file, and call it about.tsx. As we mentioned earlier, every page is a React Component. Let's create one.

[1:12] Let's name it about, and export it. Every page needs to be exported using the default keywords. We're going to return a heading called about. Let's execute npm run dev and open localhost:3000. Here's the home page.

[1:35] If we go to the about or /about, we can see the about page right here. That's how we can create new pages. In order to link between the pages, we can use the link component from the next/link package.

[1:48] Let's put our link back to the home page in the about page. First, we're going to import the link component from next/link. Let's rub the about pages in an empty React fragment, and put a link to the home page below the heading.

[2:05] The link component needs an href prop to function. Let's check it out. We can see we have the link to the home page. If we click it, we're taken back to the home page.

[2:15] It's important to use the link component instead of the ordinary anchor tag because the link component performs a client-side navigation, while the anchor tag performs a full-page reload. Let's demonstrate that.

[2:26] We're going to go to the home page, and instead of using the link component, we're going to use an ordinary anchor tag. Let's name it about and set the href to be /about. There we go. Now we have the link here. If we click this, a full-page reload will happen. Pay attention to the favicon. If we use the link component, the transition happens immediately.

[2:55] Let's recap. In Next.js, every page is a React component that lives in the Pages directory. That's how the router knows how to generate our routes for us. The index page gets mapped to the / and the About page gets mapped to the /about. To link between the pages or to build a navigation between the pages, we need to use the link component that's exported from the next/link package.

https://app.egghead.io/api/v1/lessons/typescript-create-new-pages-in-next-js-and-navigate-them-using-link/transcript

https://app.egghead.io/api/v1/lessons/typescript-create-dynamic-routes-with-next-js/subtitles

Lazar Nikolov: [0:00] In the previous lesson, we learned how to create and navigate between pages, and how Next.js generates the routes for us.

[0:07] What if we wanted to create a page where the last part changes, for example, a blog post page? That feature in Next.js is called dynamic routes. Creating dynamic routes is similar to creating ordinary pages, but their name is wrapped with brackets.

[0:22] Let's open the exercise number 3, and check out the index file. We can see that we already have some data inside. There is a heading labeled my favorite music genres, and a list of music genres rock, country, and pop. Each list item point to a page that we need to create.

[0:38] Let's right-click on Pages, click on new file, and write genre.tsx, but wrap the genre with brackets. That's how we create dynamic pages. Let's create a React component and export it.

[0:54] In order to get dynamic parts from the route, we can use the useRouter hook that's exported from the next/router package.

[1:00] First, let's import it. Now, we can get inside of the component and get the router. Const router = useRouter(). To obtain the dynamic part, we can extract it from the router.query. The name will be genre, just like how our page is named within the brackets.

[1:24] We're going to return a heading and then place the genre inside. Let's see what we get. Let's run npm run dev and visit localhost:3000. Here is the initial home page where we can see the three, rock, country, and pop genres.

[1:42] If we click on them, we can see their names in the headings. Let's go back visit country, and let's go back visit pop. We can go even further. Let's say we wanted to create a page that displays a certain comment under a certain post.

[2:02] We can create a new folder called post. Inside, we can create a new folder called PID or post ID with brackets, so it's dynamic. Inside, we can create a new file called comment.tsx with brackets, so it's dynamic.

[2:18] Let's create the React component. Import the useRouter hook from next/router. Let's obtain the router using the useRouter hook. We're going to console.log the router.query. To avoid errors, we are going to return a simple hello paragraph. Let's see what we get.

[2:44] If we go to /post/some post ID and then some comment ID and open the console, we can see that the router.query is an object that contains the PID and the comment values. This is how we can create dynamic routes that are even nested.

[3:03] Let's recap. The difference between the ordinary page and the dynamic page, is that the dynamic page's name is wrapped with brackets. Inside of the dynamic page, we can use the useRouter hook to obtain the router and get the dynamic part.

[3:18] We can even have nested dynamic routes if we place them into dynamic folders, and we'll still obtain the values from the router.query.

https://app.egghead.io/api/v1/lessons/typescript-create-dynamic-routes-with-next-js/transcript

https://app.egghead.io/api/v1/lessons/typescript-serve-static-assets-in-a-next-js-project/subtitles

Lazar Nikolov: [0:00] Aside from pages, there is another specialized folder called public. Next.js serves everything in the public folder statically starting from baseurl/. Let's open the exercise number four, and check out the index file.

[0:14] We can see on line six that we want to add the lazar.png image there. We can see that the lazar.png is at the root of the project. In order to serve it statically, we need to place it in the public folder. Let's create the public folder.

[0:30] All we need to do is drag lazar.png inside. Let's get back to the index.tsx folder, and add an image tag and set the source to /lazar.png. Ignore the warnings for now. Let's see what happens. We're going to run npm run dev and visit localhost:3000.

[0:52] There we go. We can see the image. The public folder is also useful for the robots.tsx, your favicons, the Google site verification, and any other static files including HTML files.

https://app.egghead.io/api/v1/lessons/typescript-serve-static-assets-in-a-next-js-project/transcript

https://app.egghead.io/api/v1/lessons/typescript-serve-optimized-images-using-the-next-js-image-component/subtitles

Instructor: [0:00] In the previous lesson, we learned how to serve static assets in the public folder. We had an image lazar.png, and we rendered it on the page. We can always use the good old image tag to display images.

[0:12] Next.js also provides us an image component that has some built-in performance optimizations, for example, improved performance. It will always serve the correctly-sized images for each device using modern image formats. It also guarantees visual stability by preventing cumulative layout shifts automatically.

[0:31] Faster page loads, images are only loaded when they enter the viewport with optional blur-up placeholders. As a flexibility, you get on-demand image resizing, even for images stored on remote servers.

[0:46] Let's open exercise five, and check out the index page. The index page is very similar to the last exercise, but in this case, we're going to use the image component. Let's import the image component.

[0:59] We'll do import image from next/image. When we use the image component, we don't need to put the files in the public folder. In this case, we can import lazar directly from the root. Now, we can go down to the home component and return the image component.

[1:22] We'll set the source to lazar, and we'll also set the out prop. Also, let's run npm run dev, and see what we get. There we go, there's the image. Using the image component, we can also render remote images. Let's say, we have a Twitter image that we need to render.

[1:45] Let's wrap the home component in an empty React fragment and add another image where the source is going to be the Twitter image URL. Also, let's add an out prop remote picture of lazar. In this case, we can also add a width of 250 pixels and a height of 250 pixels.

[2:21] Let's see what we get. We get an error. It says, "Invalid source prop." The hostname pbs.twimg.com is not configured under images in your next.config.js file. We don't have that file. To fix this error, let's go ahead and create it.

[2:41] In the root folder, we're going to create the next.config.js file. We need to type module.exports, provide the images property and provide the domains array. In here, we need to register the pbs.twitterimage.com. We're just going to paste it here, and restart our server.

[3:09] If we go back and refresh, we can see the remote image being rendered. Let's go and change the width and height to 550, just so you can see it change. There we go.

[3:25] Let's recap, Next.js also provides us with an image component that has some built-in performance optimizations. We can use it to render local images and remote images.

[3:35] In order to render remote images, we need to create the next.config.js file at the root of the project, and register the domain of the image in the images and domains property. That's how we can render highly optimized images in Next.js.

https://app.egghead.io/api/v1/lessons/typescript-serve-optimized-images-using-the-next-js-image-component/transcript

https://app.egghead.io/api/v1/lessons/typescript-provide-page-specific-metadata-using-the-head-component/subtitles

Instructor: [0:01] Something that every website has in common is metadata, which consists of a title, description, style links, scripts, and so on. In Next.js, we can use the head component to provide metadata for each page specifically.

[0:16] Let's open up exercise number six, and enter the index.tsx. First, let's run npm run dev and see what we get. We get a heading, but there is no title or description or anything like that.

[0:33] Let's use the head component to provide that information. We're going to import head from next/head, and add our metadata inside. The title is going to be home page, and we can add the viewport metadata. Let's save our file and see what we have.

[0:57] We can immediately see that we have the title set to home page. If we open the inspect element tab and enter the head tag, we can also see the viewport. The content in the head component can be composed of local hard-coded data, just like we did, and also, data obtained from an API or CMS.

[1:19] In order to avoid duplicates, we can use the key prop, which will make sure that the tag is going to be rendered only once. Let's simulate a situation. Let's add another head component, which we can theoretically fetch from the CMS.

[1:36] Now, let's add a metatag with the OG title as the name. Let's set the content to my Next.js course. Let's set the key to title. If we go back and refresh, we can see the OG title is here, but if we go back and add another head component, but instead we're going to change the title to my awesome course and we'll keep the key.

[2:09] In this case, this metadata is going to be rendered, while this one is going to be discarded. Let's check it out. Hit refresh. There we go, we can see that there is no other OG title tag present, and the content is my awesome course.

[2:29] The contents of the head component get cleared upon unmounting the component. Make sure that each page completely defines what it needs without making assumptions about what other pages added.

[2:41] The title, meta, or any other elements need to be direct children of the head component, or wrapped into maximum one level of React fragment. Otherwise, the tags won't be correctly picked up on client-side navigations. This is how we can add metadata for each page in Next.js.

[3:01] To recap, Next.js provides the head component that we can import from the next/head package. We can use as many of the head components as we want, and we can also fetch the metadata from an API or CMS.

[3:16] There is a key prop that prevents duplicate metadata being added into the head tag. Also, the contents of the head component must be direct children of the head component, or wrapped into maximum one level of React fragment.

https://app.egghead.io/api/v1/lessons/typescript-provide-page-specific-metadata-using-the-head-component/transcript

https://app.egghead.io/api/v1/lessons/typescript-override-the-default-app-component-in-next-js/subtitles

Instructor: [0:00] If you've worked with traditional React apps, you know that the index.tsx file is your starting file. There's a similar concept in Next.js as well, which is called the app component. Since Next.js works on the concept of pages, every page is initialized by that app component.

[0:18] By default, the app component is hidden, it's internal in Next.js, but we can override it to control the page initialization, if you want to persist layout between page changes, keep the state when navigating pages, if you want to do custom error handling, inject additional data into pages, or add global CSS.

[0:42] To override the default app, we need to create the _app.tsx file into the pages directory. Let's open exercise number seven and let's do that. Right click on pages, newfile_app.tsx. Just like any other page, the app component is an ordinary React component.

[1:07] In this case, we have some specific props that we need to define. Let's import the app props type from next/app, and define our props in the app component. The app props provide us with the component and the page props.

[1:24] Now, we can go ahead and return that component and spread the page props. This is the default configuration of the app component. Let's check it out and run npm run dev. Visit localhost:3000. We can see a heading overriding the app component.

[1:45] Let's visit the index page, and see that we have the overriding the app component here. That means nothing's changed. Everything works the same. Let's take a look at the app component.

[1:57] The component prop is your page component, which in this case, is the home component that we defined on line four. The page props is an object that contains the initial props that were preloaded by the data-fetching methods.

[2:13] If no data-fetching methods were used in that particular page, the page props object will be empty. Let's check it out. We're going to console.log page props. Let's open the console tab and check the output. There we go.

[2:35] We are logging out an object, but it's empty. The page props object represents the props for each page. To demonstrate that, let's add a title in the page props and try to obtain it from the home page.

[2:51] We'll say, "pageprops.title=this is my title." Now, we can go to the home page and obtain the title. The title will be string. We can obtain it from the props. Instead of overriding the app component, we're going to pass the title in the heading. Let's check it out. There we go. We can see, "This is my title."

[3:19] In some of the following lessons, we'll be doing data fetching, that can be either server side or static. The data that we're going to fetch will be passed in our page through the page props object. Let's recap. The _app.tsx is something similar to the index.tsx in traditional React apps.

[3:39] This is how Next.js renders every page. To define the app component properly, we needed to import the app props type from next/app and obtain the component and page props through the props.

[3:52] The component prop is our actual page. The page props is the data that our page receives. If the page receives no data, the page props will be empty.

https://app.egghead.io/api/v1/lessons/typescript-override-the-default-app-component-in-next-js/transcript

https://app.egghead.io/api/v1/lessons/typescript-override-the-default-next-js-document/subtitles

Lazar Nikolov: [0:03] In the previous lesson, we learnt what the App component is, how to override it, and in which cases we want to override it.

[0:11] There's a similar concept in Next.js called the document. We can use a custom document to augment our applications HTML and body tags. For example, setting the language property of the HTML tag, add third-party scripts, link custom fonts, add analytics scripts, etc.

[0:32] To override the default document, we need to create the _document.tsx file into the Pages directory. Let's do that in exercise 8. Right-click on Pages, new file _document.tsx.

[0:49] Just like before, we need to export a default function called document, and we need to return something. Now in the case of the document, there are some things that we have to include in order everything to work properly.

[1:09] Let's import them from the next/document package. Those things would be the HTML components, the head component main, and next script. Let's go into the function and return this. First, it's the HTML component.

[1:30] This is basically the top-level HTML tag in every HTML document. Then is the head component. In this case, we don't have any children that's why it's self closing, but you have the ability to put additional stuff into the head component.

[1:44] Then our body, which is a simple HTML tag, we don't actually import the body as a component. Inside of the body, we have the main. That's where all of our pages render. We have the next script. This is the default configuration for the document.

[2:07] Let's run npm run dev and see what we get. There we go. We can see a document. We are overriding the document in Next.js. Nothing to see here. Nice. No errors, everything works perfectly. One thing that I need to mention, is that the document is only rendered in the server, so EventListeners like onClick will not work.

[2:34] As I mentioned earlier, we can override the document if you wanted to add the language property to the HTML, or add custom analytics scripts, or change the favicon. Let's try doing that.

[2:47] Before we make any changes, let's inspect our document. We can see that the HTML tag is here, the head tag contains some default elements from Next.js, here is our main component, and we have some additional Next.js scripts below.

[3:12] Let's go back and let's try to set the language property to English on the HTML itself, let's try to expand the head component. For the sake of simplicity, I will just paste a code snippet that will change the favicon to a cross on. Let's save this, and check out the changes.

[3:38] We can immediately see that the favicon is changed to a cross on, and we can see that the language is changed to English on the HTML tag. That's how you can override the document.

[3:53] Let's recap. Just like the App component, we can also override the document by creating the _document.tsx file into the Pages directory. We need to export a default function named document, and return the HTML head, main, and Next script in order for everything to work.

[4:12] Additionally, we can also add support for localization, change the favicon, we can also add our analytics scripts, or we can link custom CSS, custom fonts, etc.

https://app.egghead.io/api/v1/lessons/typescript-override-the-default-next-js-document/transcript

https://app.egghead.io/api/v1/lessons/typescript-style-your-next-js-app-with-global-css-css-modules-and-css-in-js/subtitles

Instructor: [0:00] Every website needs its own custom styling, and Next.js makes no exceptions in that. There are several ways to achieve custom styles by adding a global style sheet, component level CSS, CSS in JS, or use a UI framework, but we'll cover that in a separate lesson.

[0:20] In this lesson, we're going to focus on the first three. Let's start by adding a global style sheet. Let's open exercise number nine, open the Styles folder, and the globals.css file. We can see that in this style sheet, we are adding some basic styling to the body element.

[0:39] To apply these styles, we need to import this CSS file into the App component. Let's open up the Pages directory and the _app.tsx. To import that CSS file, we just need to do import and the relative path to the file. We'll go up one level, Styles, and then globals.css.

[1:03] Let's run the app and make sure that the styles are applied. We'll do npm run dev. Let's open up inspect element and click on the body element. On the right side in the styles tab, we can see that the styles that we defined in the globals.css are applied to the body element.

[1:26] Since we imported the CSS file into the app component, those styles will get applied on every page. That's how we can use global styles. Next, let's see how we can use the component-level CSS method.

[1:40] Another way of achieving custom styles is using CSS modules, which Next.js has support for. Let's say, we have a reusable button component in the sources directory, components, button, and the button.tsx file.

[1:55] To create the CSS module for this component, we need to create a new CSS file into the button directory, right next to the button.tsx file. We should name it, button.module.css.

[2:08] The fact that the CSS file is right next to the component file, and the CSS file name is exactly like the component file name, but ends with .module.css, Next.js will treat this as a CSS module. Let's create a simple CSS class. We'll call it error.

[2:26] Let's set the color to white and the background color to red. In order to use this class into our component, we need to go back to the button.tsx file, and first import the styles, but this time we will import styles from button.module.css.

[2:49] The styles in this case represents an object that holds all of our CSS classes inside of that style sheet. In order to apply it to the button, we can use the class name prop, and set the class name to styles.error.

[3:06] Let's save this file and check out the login button. We can see right off the bat that the button is red with white text. If we inspect it, we can see that it has a custom generated class name, which in this case is button_error, and then some sort of ID.

[3:26] This means that Next.js recognized the style sheet as a CSS module and generated that class for us. We can also see that the styles that we wrote are contained within that class. This is how we do CSS modules in Next.js. Lastly, let's see the CSS-in-JS method. Next.js also comes with a built-in CSS-in-JS support.

[3:52] The simplest way to do CSS-in-JS in Next.js is by doing inline styles. Let's go to the index page into the pages directory and focus on the first div. We'll apply styles using the CSS-in-JS support, we can use the style prop. The style prop receives an object with style definitions, but in CSS-in-JS syntax.

[4:18] Let's set the display to flex, flex direction to row, the row gap to 24 pixels, the justify content space between, and the aligned items to sender. Let's save this and see what we get. We can see that the layout has changed.

[4:51] If we focus on the first div, we can see that those styles are translated into CSS and are in lined to the div that we edited. Awesome, that's about it. That's how we can use CSS-in-JS in Next.js. Let's recap. First, we learnt about the global style sheets method, where we have a CSS file just like this one and we wanted to apply it to every page.

[5:15] We simply imported it into the app component file and the changes got applied immediately. Then, we learnt about the CSS modules method, where we created a CSS file with the same name as the component file that ended in .module.css.

[5:31] We have imported this file in the component file itself, but imported it just like we import an ordinary package. The styles, in this case, represented an object that had all of our classes inside of that CSS module.

[5:46] The last method that we learned was the CSS-in-JS. We learned that we can inline the CSS by using the style prop, and provide an object with our style definition using CSS-in-JS syntax. These styles got compiled into ordinary CSS and applied back to the div.

https://app.egghead.io/api/v1/lessons/typescript-style-your-next-js-app-with-global-css-css-modules-and-css-in-js/transcript

https://app.egghead.io/api/v1/lessons/typescript-create-custom-layouts-in-next-js-to-apply-to-all-or-individual-pages/subtitles

Lazar Nikolov: [0:00] React's composable nature allows us to create reusable components, and layouts are exactly that. In lesson number seven, we learned what's the app component and how to override it. If we had a custom layout and wanted to use it, the App component is where we should start.

[0:17] In Next.js, there are two ways that you can define a custom layout. You can define a single shared layout, or you can do something more complex and build a per-page layout system. In this lesson, we're going to cover both of them.

[0:30] Let's start with the single shared layout. A single shared layout in Next.js is a custom layout that's used by every page in our app. For example, let's say that our app is simple and every page has a navbar and a footer.

[0:43] Let's open up exercise 10. Let's open the Source folder components layout, and open the index.tsx file. Before we jump into the index.tsx file, we can see that we have a footer and navbar files at the same level.

[0:58] If we open those files first, we can see that we have some sort of an initial layout. To hook everything up, let's go to the index.tsx file, and check it out first. As you can see, the layout component is a standard React component.

[1:14] In this case, we have the children-defined in the props. The children will be the page itself. What we need to do now in order to display the navbar and the footer is first import them.

[1:26] We will do import navbar from navbar, and also import footer from footer, and then go down into the layout component, expand the empty React fragment. First, let's add the navbar.

[1:46] Then, we can add the children or the page itself. Lastly, we can add the footer. This is how we can define a layout. In order to use this layout or to apply it to every page, we need to go to the app component, pages_app.tsx.

[2:06] As we mentioned earlier, in lesson number seven, the app component renders every page in our app. In order to use the new layout, we need to import it first. We're going to say import layout from. We're going to jump one level up, source, components, and then layout.

[2:25] After we have it imported, we can wrap the component with our layout. Let's say, layout right here and put the closing tag below the component. There's no need to pay attention to the Chakra provider for now, because we'll learn more about it in the next lesson.

[2:42] Let's save this and execute npm run dev to see it in action. If we refresh our page, there we go. We can see that the title is here. There's a login button. This is our home page content, and then the footer contains three columns of links.

[3:00] Let's confirm. If you go to the index page, which is the home page, we can see that we only have the heading. This is our home page content.

[3:10] Everything else is defined by that layout component that we learned about. Since the layout component is being used in the app component, it is reused when changing pages. The component state will be preserved. That's about it for the single shared layouts.

[3:29] Let's take a look how we can define per-page layouts. For example, if we have a much bigger website that has multiple layouts, for example, authentication, dashboard, settings, etc., we can define a getLayout property to our pages that will receive the page in the props and wrap it in the layout that we want.

[3:49] Since we're going to be returning a function, we can have complex nested layouts if we wanted to. Let's take a look how we can do that. First, let's get rid of the layout component, the single shared layout that we just did.

[4:03] There we go. Now, we're ready to take a look at the per-page layout. For this to work, we are going to open the home page. As we mentioned, we can define a getLayout function on the home component itself, that will take the page in its props and wrap that page with a certain layout.

[4:19] To define the getLayout method on the home component itself, we can attach it by doing home.getLayout=, and then the arrow function. The point with this method is to actually call it from within the app component.

[4:36] Since we have the component from the props in the app component, which represents our page, we can pass that page in the props of the getLayout. We can do page, and then that will be of type React element, and make sure to import it.

[4:54] The getLayout method can be considered as a component itself. For example, in this case for the home page, we want to use the layout that we previously did. We're going to import it and inside, pass the page from the props. That's it.

[5:09] Right now, if we refresh, we won't see any changes because we need to utilize or to call the getLayout method. Let's go to the app component and do some changes. As we mentioned earlier, the component that we get from the app props is the actual home page. Right now, that component contains the getLayout method that we just defined.

[5:30] In order to obtain it, let's create a new constant called getLayout, which will equal to component.getLayout in case it exists or as a fall back, we can create a simple inline method that takes the page in the props and returns the page without making any changes.

[5:50] Now, in order to use the getLayout method, we need to use it in place of the component. We'll open curly brackets and write getLayout, and because it needs a page, we can paste our component. There we go, we can immediately see the changes.

[6:05] We have the heading, we have the button, and the footer with all of the links inside, but there are some errors. If we hover on the getLayout, TypeScript will complain that the property getLayout does not exist on the type Next component type.

[6:18] If this was JavaScript, we won't have any problems. In order to make TypeScript happy, we need to do some changes. Because we're using the AppProps, the component type that is defined from the AppProps does not include the getLayout method, because that is our own custom method.

[6:36] The solution would be to create our own AppProps type and override the component type, so let's do that. We can create a type above the App component, and let's name it AppPropsWithLayout.

[6:50] This will inherit or extend the AppProps that we already have from the Next /F package, but then we will override the component type.

[7:02] Since our new getLayout method is part of the component type, we need to create yet another type that will include our new method inside. Let's call that one NextPageWithLayout and define it above the AppPropsWithLayout.

[7:17] Let's see. Type NextPageWithLayout that will inhibit from NextPage, and then add our getLayout method. As we defined it, it will receive a page, which was of type React element, and it will return a React node.

[7:41] Now, if we were to replace the AppProps with our AppPropsWithLayout, all of the errors are gone. If we hover on the component, we can see that it extends the NextPageWithLayout. If we trigger the intelliSense, we can see that our getLayout method is now being discovered.

[8:00] Since we defined it as an optional, we need to provide the fallback. This is how we can build a simple per-page layout mechanism, where we can define which layout will be used for each page specifically.

[8:16] One thing to note that the custom layouts are not considered as pages, so the only way to fetch data is on the client's side. We can't use Next.js' data fetching methods.

[8:28] Let's recap. We learned that there were two ways to achieve custom layouts in Next.js. There was the single shared layout, which we defined in the source components layout file.

[8:40] This was a simple React component that accepted children in its props. In order to use it, we wrapped our component in the layout itself. That's how all of our pages will have that layout.

[8:52] We also learned about the per-page layout mechanism that will allow us to specify which layout will be used for each page. To achieve that, we defined a getLayout method for the page itself. In this case, it was the home page that accepted the page and its arguments, and rendered that page in the specific layout that we want.

[9:14] In this case, we used the previous layout. If this was an authentication screen, then we would define a new register layout or login layout or authentication layout, and we would have used that one instead.

[9:25] To hook up everything and make it work, we obtained the getLayout method from the component itself, which was the page. We also provided a fallback in case a certain page does not define its own layout, and then we use that method to render the component that we get from the props.

[9:42] Then, we went the extra mile to make TypeScript aware of our new method, and we created the AppPropsWithLayout and the NextPageWithLayout types, so that our component that we get from the props will be aware of the getLayout method that we just defined.

https://app.egghead.io/api/v1/lessons/typescript-create-custom-layouts-in-next-js-to-apply-to-all-or-individual-pages/transcript

https://app.egghead.io/api/v1/lessons/typescript-super-charge-your-next-js-development-with-ui-frameworks-like-chakra-ui/subtitles

Lazar Nikolov: [0:01] In lesson number nine, we learned how to create a new CSS files or custom styles. Most of the developers use UI frameworks to make their lives easier. Using a UI framework like Chakra UI, in combination with Next.js, will supercharge your feature development and make the styling of your app even easier.

[0:20] Frameworks like Chakra UI, utilize the React Context API to configure your web app's theme, and ensure consistent styles. As we mentioned in lesson number seven, we can overwrite the app component to persist layout between page changes and inject additional data into our pages.

[0:38] That's where we can add the Chakra provider. Chakra UI also comes with a ColorModeScript, specifically built for Next.js that we need to put in our custom document, which we learned how to overwrite in lesson number eight.

[0:51] Let's check out our project. Let's open exercise number 11. Let's open the pages directory, and open index.tsx.

[1:01] To make things simple, I've already included a prebuilt interface built with Chakra UI, so we can go through the installation process without having to write any UI code. I've also included a theme.ts file, that uses the extent theme method from Chakra UI to set the initial color mode to light and disable the system color mode.

[1:22] Let's begin. If we open up Chakra UI's website and click on the Get Started button, we can see that there is already a guide for Next.js. Let's select that. What we need to do is copy the installation script. This installs Chakra UI, and all of its dependencies.

[1:39] Let's go back to our project and execute that installation script. We'll let this run in the background. As we mentioned previously, to set up Chakra UI, you need to set two things, the Chakra provider and the ColorModeScript.

[1:53] Let's set up the Chakra provider first. We'll open the app.tsx and import the Chakra provider first. We'll do import Chakra provider from Chakra UI/React.

[2:06] While we're here, let's also import our theme, from our theme.ts file. To set up Chakra UI, we need to wrap our component with the Chakra provider.

[2:23] Let's also not forget to set the theme in the theme prop. That's it. Let's run npm run dev and see it in action. There we go. We can see that this page has its own custom styles. To finish the Chakra UI installation, let's not forget to add the ColorModeScript. Let's open the document.

[2:48] First import the ColorModeScript. We'll do import ColorModeScript from Chakra-UI/React. Because it needs our theme, we can also import our theme while we're here. Import theme from theme. Now, above the main script, we can add our ColorModeScript.

[3:10] To hook up the initial color mode, we need to set the initial color mode prop to theme.config.initialColorMode. That's it. Let's just restart our server. We'll run npm run dev again, and ensure that everything is OK.

[3:33] Nice, there we go.

[3:36] Let's recap. We learned how one UI framework in this case Chakra UI integrates with Next.js. We learned how to set up the Chakra provider within our app component, and also how to set up the ColorModeScript within our custom document.

[3:54] Most of the UI frameworks like Chakra UI, require you to modify the app and document files to set up their contexts and their additional scripts.

https://app.egghead.io/api/v1/lessons/typescript-super-charge-your-next-js-development-with-ui-frameworks-like-chakra-ui/transcript

https://app.egghead.io/api/v1/lessons/typescript-understand-ssg-isr-and-ssr-rendering-methods-used-in-next-js/subtitles

Instructor: [0:00] Data fetching in Next.js allows you to render your content in different ways, depending on your application's use case. These include pre-rendering with server-side rendering or static generation, and updating or creating content at runtime with incremental static regeneration.

[0:18] Next.js gives you the possibility to use different rendering methods for each page individually, as opposed to using SSR or SSG for your whole website. In this lesson, we're going to explain the concepts of SSG, SSR, and ISR, and how they work.

[0:35] In the next two lessons, we're going to see how to actually implement them in our Next.js app. Let's begin. Let's start with static generation. Before we dive in, let's learn how this diagram works.

[0:49] The database server, your computer, and the browser are called actors. These represent all of the moving parts in our app. These lines that you see here are the process lines. As you can see, they also have a number assigned to them, which is the order of the execution.

[1:08] In SSG or static generation, it starts with your computer or the CI/CD machine. Let's say you run npm run build. Next.js will then query the necessary data from the database for every page.

[1:21] After it has the data, it will build the Next.js project and prepare it for production. When that's done, you can deploy the bundle to the server. That server can be your own dedicated Linux server or a CDN like Vercel.

[1:37] After you deploy your website, it is now live and users will be able to visit it. That's when the browser comes into play. The browser actor is the user, regardless of where the user is accessing your website from. It can be a laptop or a mobile phone, etc.

[1:53] A user lands on your page, it will request the website from the server, in this case, let's say Vercel. Since Vercel has the bundle that you deployed, it will immediately return the pre-built website. This will happen for every next user.

[2:08] It will request the website and Vercel is going to return the pre-built website. The good sides of this static generation method is that the websites are super fast. There is little or no JavaScript involved. The data is already pre-fetched.

[2:22] When the browser receives the package from the server, it can start to render the page immediately. The downside of this method is that we have static data. As you can see on this side, the data gets updated only when we run npm run build.

[2:37] There is no connection between the server and the database. If you update your data, you will need to run npm run build again to obtain the new data, rebuild your Next.js project, and deploy the new bundle.

[2:50] After that, the users will be able to access the new data. That's how SSG works. Let's move onto the server side or SSR. As you can see, it's pretty similar to SSG, but the database is connected with the server as opposed to your computer. Let's start.

[3:07] First, you run npm run build, and you build your Next.js project. After you've done that, you deploy the bundle to the server. After you've deployed the bundle to the server, your website is live and can be accessed.

[3:21] A user comes in and requests your website. This time, instead of returning the pre-built website immediately, the server will first query the data from the database, generate the HTML for that page with that data, and then return the pre-built website.

[3:37] If another user lands on your page, the server will again query the data, generate the HTML, and then return the pre-built website.

[3:46] As opposed to the previous method, we now have live data meaning if we add something to our database, it will be immediately available on our website because the server generates the HTML for each request. If 1,000 users land on our website, the server will query the database and generate the HTML 1,000 times.

[4:06] The good side of this method is that we have dynamic data, but the bad side of this method is that our server is going to have to work much harder than the previous method. It will need to query the database and generate new HTML every time a user lands on the page.

[4:23] Another downside of this method is that the browser will need to wait for the server to query the data and generate the HTML, and then return the pre-built website to the browser, even though nothing has changed from the previous request.

[4:38] That is server-side rendering. Now, let's move on to the ISR or incremental static regeneration. As you can see, this is a hybrid between the SSG and SSR. We have connections to the database from both, our computer and the server.

[4:53] Let's see how this works. When we run npm run build, the Next.js server will query the necessary data from the database and then build the Next.js project. As soon as that's done, we deploy the bundle to our server, but this time, it's marked with version one.

[5:09] Let's say a user lands on our website. It will request the website, and then the server will return the version one immediately because it already has that one. In the meantime, the server will query the page data from the database in case there is new data.

[5:26] It will regenerate that page and overwrite the old version as version two. It will continue to serve that one. When the next user comes in, they will request the website, but the server will immediately return version two of the website.

[5:42] The same thing will happen again. After the second user, the server will query the page data from the database. It will regenerate if there is new data as version three, and it will continue to serve version three from that point on.

[5:58] Even though this looks like SSR, querying the data, regenerating the page on every request, it doesn't actually happen on every request. In Next.js, we can configure a timeframe in which a certain page will be regenerated maximum one time.

[6:15] For example, if we set the revalidation or regeneration of the page to one hour, it will only regenerate the page once within that hour. The first user lands on our website, query the page data, regenerate the page, and keep serving that one.

[6:30] Every other user that lands on our website within the next hour will receive version two, but they will not trigger the query the page data and the regenerate the page process flows.

[6:43] That's how incremental static regeneration or ISR works. The benefits of this method is, just like the SSG method, we get static data and we return it to the user immediately. We get the speed of static generation.

[6:57] We also have dynamic data because the server will periodically query the database and regenerate the page if there is demand for it without us having to rebuild the Next.js project and deploy the newer version.

[7:10] Those are the three data-fetching methods in Next.js. Let's recap. We learnt about static generation or SSG, where the page gets generated when we run npm run build. All of the necessary data is queried from the database.

[7:28] The Next.js project gets rebuilt, and we deploy it on the server. The server will then serve the bundle that we deployed. We had faster response rates, but no dynamic data. Then we learnt about the server-side rendering or SSR, where pretty much the same thing happened.

[7:49] We built the Next.js project and deployed the bundle, but the server queried the database and generated the HTML on every request. We had slower response rate, but we had dynamic data.

[8:03] Then we learned the incremental static regeneration method, where we generated some initial data, rebuilt the project and deployed the version one on our server. The server then immediately returns version one to our users, but in the meantime, queried the database, regenerated the data and continued serving version two.

[8:23] This way, we had the response speed of static and also dynamic data of server side.

https://app.egghead.io/api/v1/lessons/typescript-understand-ssg-isr-and-ssr-rendering-methods-used-in-next-js/transcript

https://app.egghead.io/api/v1/lessons/typescript-statically-generate-pages-using-ssg-and-isr-with-next-js-getstaticprops-and-getstaticpaths/subtitles

Lazar Nikolov: [0:01] All right. Since you understand now how data-fetching methods work in Next.js, we can start to implement them.

[0:07] In this lesson, we're going to cover the static generation or SSG, and the incremental static regeneration or ISR.

[0:15] Let's open Exercise 12. Let's open the pages directory, and the index.tsx file. This is our home page. One thing that you can notice is that this component now accepts props, which in this case is a string array called genres.

[0:32] These genres are then mapped out in a list. This is how we obtain the data from any data-fetching method in Next.js through the props.

[0:42] Let's implement the static generation method in this page.

[0:45] Just a quick refresher. The static generation generated the data at build time or when we run npm run build. It generated all of the HTML files for us, which we then served statically.

[0:57] Let's begin.

[0:58] To use the static generation method in this page, first, we need to import the getStaticProps type from next.js. So, we'll do import type, getStaticProps from next. Now, let's go to the bottom of the file. Just above the export default, we can export a new method called getStaticProps.

[1:17] Let's also set the type of this method to getStaticProps. Since it's a generic type, we can pass our own props to it. Inside of the method itself, we can do return props and then our prop type define genres. Genres, and we can define rock, country, and pop. That's it.

[1:43] Let's run npm run dev to see it in action. There we go. We have the genres title and we have the list of genres that we passed. If we add another one let's say, indie and refresh the page, we can see the new genre in the page.

[2:05] This is the simplest form of the static generation data-fetching method. One thing to note that the getStaticProps method must be named as getStaticProps in order to work.

[2:16] Also, Next.js strips away this method from the bundle. Meaning, when the user visits the home page, they will not receive this method, and they won't be able to look at the code. That feature makes this method safe for us to use database connections, or any API secrets that we don't want to be exposed.

[2:35] The static generation for dynamic routes or dynamic pages, requires some additional configuration to work.

[2:42] Let's create our genre page. Right click on the pages directory, New File. Let's call it genre.tsx, but with brackets around this name to make it dynamic. Let's create a genre component. We'll return a Hello text and export default genre.

[3:03] Let's implement the basic getStaticProps method here. First, let's create a type props for our props and we can say, "Genre is a string." We will display the genre in this case. Now, we can add the props type to our props on the component. Then we can replace the Hello text with the genre from the props.

[3:30] Awesome. Now, we can do import type getStaticProps to import the getStaticProps type from the next package, and export the getStaticProps method.

[3:42] We need to return an object that contains the props. In this case the genre, let's hard code it to rock. Since the static generation builds all of the pages at build time and this is a dynamic page, we need to tell Next.js which pages it should generate for us.

[4:00] In order to do that, we need to export another method called getStaticPaths, which return an object with the paths that we want Next.js to generate for us. Let's also import the getStaticPaths type from next, and export another method called getStaticPaths, which uses that type. getStaticPaths.

[4:24] As I mentioned, we need to return an object that included the paths and let's say, for example, we will only support rock, country and pop for now. We need to map these genres and return an object for each genre that has the params property. Inside of the params property, we need to add the genre.

[4:48] Aside from the paths property, we also need to provide a fallback property and set it to false. The paths property tells Next.js which pages it should generate. In this case, we want to generate rock, country, and pop.html files.

[5:04] The fallback property is a key that we must include in our getStaticPaths results. If it's set to false, like in this case, then any paths that are not returned by the getStaticPaths method will result in a 404 page.

[5:19] In this case, we have the indie genre, but since it's not included into the paths, it will result in a 404 page. If we set the fallback to true, Next.js will render a fallback page while it statically generates the HTML and JSON for this page. This includes running the getStaticProps again.

[5:39] When it's done, the page will receive the brand new data in its props, and it will render its contents. At the end of the process, Next.js will also add the new path to the list of pre-rendered pages. When we visit the indie page next time, it will not regenerate it.

[5:56] We can also set the fallback to blocking. This is very similar to the true value. In this case, Next.js will not render a fallback page, and it's going to make the browser wait for it to generate that page.

[6:10] Let's bring it back to false. Before we continue, let's go back to the index page and make the genre links.

[6:20] We're going to import the link component from next/link and wrap the genre with it. We need to provide an href. It will be "/genre." For rock it will be "/rock." For country it will be "/country," etc. Let's save this.

[6:39] As we can see, the cursor changes. If we click on "Rock," we can see that we navigated to /rock. We can see the genre name displayed. If we go to country, we can still see rock because we hard coded it. Let's go back to the genre page and let's fix that.

[7:00] Since this is a dynamic page and the getStaticProps method doesn't get sent to the user, we cannot use the use router hook that we used previously to figure out what is the current genre. We can check the genre from a different place.

[7:14] The getStaticProps method accepts a context in these arguments. The context is an object that holds data like default locale, locale, and locales, which are internationalization properties.

[7:25] Locale is a string array that holds all of the supported locales. The locale is the currently active locale. The default locale is the default locale. Then we have a property called params. These are the route parameters for pages that use dynamic routes just like this one.

[7:44] Then we have the preview Boolean, which is true if the page is in the preview mode. That's an advanced feature, and we won't be covering it in this course, and also the preview data which holds the data if the page is in preview mode.

[7:58] Let's obtain the genre from the context.params property. We can write const genre = contexts.params. This could be undefined. We need to optionally try to obtain the genre from the parameters. Because the parameters return a string or an array string, we need to cast it as a string because it's a single segment in our case.

[8:21] If we're unable to obtain the genre from the context, we can return a new object and set the notFound property to true. This is a known property to Next.js. If it receives a notFound Boolean set to true, it will render a 404 page. If the genre can be obtained, instead of hard-coding it, we can return the genre.

[8:45] Let's refresh and see what changes. There we go. We are in the country page, and we can see country. If you go back and open the pop page, we can see pop. If you go back and open the indie page, it will result in a 404 page because we did not include it into the getStaticPaths method.

[9:07] If we set the fallback to true and hit refresh, we can see the indie genre displayed there. This is how we can implement static generation in dynamic pages.

[9:19] To make sure that we actually use static generation, we can check from the Next.js build output. Let's run npm run build and see the output.

[9:31] There we go. Here is our home page and here is our genres page. As we can see, they are marked with a filled-in circle before them. If we look down at the legend, we can see that the filled-in circle represents an SSG page automatically generated as static HTML plus JSON or uses getStaticProps.

[9:55] In order to demonstrate that we are fetching the data at build time, we can add a simple console log statement in the getStaticProps. We'll say, "Fetching data in getStaticProps. If we run npm run build again, we can see the output fetching data in getStaticProps three times.

[10:20] We have four pages. Why is that? We had three pages into the getStaticPaths. Next.js will only generate the HTML for those pages, but not the indie, even though we saw it because we had the fallback true.

[10:37] Let's run this. We'll do npm start. We can see the fetching data in getStaticProps gets outputted again because we are in the indie page.

[10:49] As we mentioned, we did not include it into the getStaticPaths method. Because we set the fallback to true, Next.js regenerates it. Meaning, it will execute the getStaticProps method again, and that's why we can see the console output here, and it will add it to the pre-built website.

[11:09] It doesn't matter how many times we refresh, we can only see the fetching data in getStaticProps logged out just once. If we go back to the rock genre, country, or pop, we will not see the fetching data in getStaticProps.

[11:24] All right. That's how you implement static generation or SSG.

[11:28] Now, let's look at the Incremental Static Regeneration or ISR. To use ISR in this page, all we need to do is return a revalidate property after the props, which will be the number of seconds in which the server will revalidate the page only once. For testing purposes, let's set it to five.

[11:49] In order to see that, we need to rebuild the page. npm run build. We can also make sure that we're using ISR. There we go. If you look at the genre page, we can still see the filled-in circle, but now we have ISR of five seconds. Good. That means we are using ISR.

[12:07] Let's run npm-start to run the server, and reload this page. As you can see, we have the fetching data in getStaticProps logged out, even though we had the pop genre supported in the getStaticPaths.

[12:24] If we run refresh again, we can see the fetching data in getStaticProps gets logged out again. This means Next.js will execute getStaticProps again. If there's new data, it will be included. If we start refreshing, we can see that the fetching data in getStaticProps gets logged out on roughly every five seconds, but not on every refresh.

[12:48] If we stop refreshing and wait for five seconds, the fetching data in getStaticProps will not be printed out. As we mentioned, ISR does not function like a cron. It will not regenerate on every five seconds.

[13:10] If we refresh now since five seconds has passed, we should be able to see another fetching data in getStaticProps log out. Let's try that. There we go. This is how you can implement ISR. Let's recap.

[13:25] We learned that we can obtain the data fetching methods data through the props, just like we can see here. To implement the static generation method, we needed to import the getStaticProps type from next, and export our getStaticProps method.

[13:45] We learn that this method was safe for us to use any database connections or API secrets, and we can prepare our data anyway we like. We need to return the data, then we can obtain it from the props. This was for static pages.

[14:03] Then we learn that for dynamic pages, we also need to export getStaticPaths method that tells Next.js which pages should be generated at build time. In our case, we generated rock, country, and pop.

[14:17] We learned about the fallback property and the different behavior that it can provide. We also learned how to enable Incremental Static Regeneration or ISR by providing the revalidate property.

https://app.egghead.io/api/v1/lessons/typescript-statically-generate-pages-using-ssg-and-isr-with-next-js-getstaticprops-and-getstaticpaths/transcript

https://app.egghead.io/api/v1/lessons/typescript-dynamically-generate-next-js-pages-with-server-side-rendering-using-getserversideprops/subtitles

Instructor: [0:00] So far, we've learned about Next.js' Static Generation method and ISR. In this exercise, we're going to explore the Server-Side Rendering method. Just like the Static Generation, SSR is another way of data fetching supported in Next.js.

[0:15] The difference between SSR and SSG, is that the in SSR, the data gets fetched for every request, while in SSG, the data used to be fetched from build time. This method is good for pages that have dynamic data -- data that changes often.

[0:30] When a user requests an SSR page, the server fetches the data. It queries the DB. It uses third-party APIs, etc. Then it generates the HTML, and then it gets it back to the browser. Compared to the SSG method, the requests in SSR are slower, but that's the price to pay to have dynamic data.

[0:51] Let's open exercise number 13. Open our pages and the index.tsx page. The initial code that we can see here is the solution to one of the previous lessons when we used the Static Generation method. Let's refactor this page to use the Server-Side Rendering method instead.

[1:12] Instead of the getStaticProps, we are going to import getServerSideProps from Next. We're going to scroll down rename the method to getServerSideProps. It will inherit from the getServerSideProps type. That's it.

[1:32] If we run npm run dev, and hit refresh, we're going to see our page functioning properly. Just to demonstrate that we are using SSR, we're going to add a console.log statement inside of the getServerSideProps. Let's logout fetching data.

[1:54] Now, let's run npm run build, so we can build the SSR page. We can also see that the index page is prefixed with a lambda symbol. That lambda symbol indicates that this page is a server-side rendered page.

[2:09] It uses either getInitialProps or getServerSideProps. Let's run npm start, and hit refresh. We can see fetching data gets logged out every time we hit refresh. Awesome. Let's talk about the differences between the getStaticProps and getServerSideProps.

[2:31] First, let's check out the context. We can see that the context is very similar to the getStaticProps context, but it has some additional properties. Like the query for example, which is an object representing the query string.

[2:46] We can use the query property to obtain the dynamic parts of our URL. We can also see the request or req for short and the response or res for short. The request property or req is the HTTP IncomingMessage object.

[3:02] Plus, it has some additional ParsingHelpers. Basically, the request is an object that contains all of the request information that the user has sent. It contains the headers, the cookies, and we can also use them to check for authorization.

[3:19] Another difference between the SSR and SSG is that for dynamic pages, we don't need to provide a method similar to the getStaticPaths because every request generates an HTML file. No HTML files need to be generated at build time.

[3:34] Let's recap. The difference between SSG and SSR was that in SSR, the page gets generated on every request. Every time a user lands on our page or we hit refresh, the Next.js server will gather all of the data needed for that page, whether we connect to a database or use third-party API services.

[3:56] Then Next.js will generate the HTML and return it back to the browser. This data-fetching method is more suitable for pages that have dynamic data, or data that changes often. Implementing SSR in a page is very similar to the Static Generation method.

[4:13] Instead, we export a getServerSideProps method. It uses the getServerSideProps type from Next. That method received a context into its arguments, just like SSG. It additionally, had the request, response and query objects.

[4:30] Unlike SSG, with SSR, we don't need to provide a method similar to the getStaticPaths when we have dynamic pages because every request generates an HTML file. No HTML files need to be generated at build time.

https://app.egghead.io/api/v1/lessons/typescript-dynamically-generate-next-js-pages-with-server-side-rendering-using-getserversideprops/transcript

https://app.egghead.io/api/v1/lessons/typescript-define-and-use-next-js-api-routes-to-make-server-side-requests/subtitles

Lazar Nikolov: [0:00] We've reached the last Next.js feature for this course, and that's the API routes. Since Next.js is built on top of Node.js, it also allows us to define our own API routes.

[0:13] The API routes are functions that are part of the server, but instead of rendering HTML, they're returning JSON data. Any file inside of the pages/API directory is mapped to /API, and it will be treated as an API endpoint instead of a page.

[0:28] These functions are server sites and will not be bundled with our client-side code. That means we can safely open database connections and use secret environment variables.

[0:38] For new projects, we can build our entire API with API routes. If we already have an existing API, we don't need to forward our API calls through an API route. We could also use API calls, if we want to mask our API or an external service.

[0:55] Before we dive in, let's check out the project. Let's open exercise number 14, and open index.tsx file. Let's also run it. We'll do npm run dev, and hit refresh.

[1:10] We can see that the starting app has two sections. The first one is a list of demo users, and the second one displays the details for every selected user.

[1:21] If we try clicking on the users, nothing happens. We're going to implement an API route that returns the selected user details. We can see that we have a fetchUser method that accepts the user ID and sends an HTTP request to an endpoint which we'll need to define.

[1:44] Let's begin. Inside of the Pages directory, let's create a new folder and call it API. Then inside of the API folder, we'll create a new folder called Users. Inside of the Users folder, we will create a new file called userID.ts. We will wrap the user ID with brackets, because we need to get the user ID.

[2:08] This is very similar to how we created dynamic routes. To build our API handler, we need to create a new method called handler, which is an async method and do export default handler. The name doesn't really matter.

[2:27] Because we're using TypeScript, we can also import the type NextApiHandler from the Next package, and set that type to the handler method, so NextApiHandler.

[2:42] Every API route accepts two parameters, that is the request and response. The request is an instance of the http.IncomingMessage object plus some pre-built middlewares. The response is an instance of the http.ServerResponse object plus some helper functions.

[3:03] Let's see what's inside of the requests. We can see that we have a body property, which contains the body of the HTTP request that the user has sent, we also have the cookies object that could contain the authorization cookie of the user sending the request.

[3:20] We can see that we also have the method property, which describes the type of the HTTP method that this API handler will receive, so it can be GET, DELETE, PUT, POST, etc. We have the query property that contains all of the query values from the URL, which in this case, we have the user ID.

[3:41] Let's start. Because this method is going to be a GET only method, we can provide an IF condition based on the request.method. If the method is a GET method, then we will handle it. Otherwise, we need to return an error that says the method is not allowed.

[4:01] We can do return and then use the response object to send a status of 405, and return a JSON with an error property of method not allowed.

[4:16] Now, this means if someone sends an API request to our handler which is not of type GET, they will receive a 405 error, which says method not allowed. Nice.

[4:27] Now, let's get inside of the IF condition. First, we can obtain the user ID by the request.query that we just mentioned. So userID = request.query.userID, and we will cast it as a string.

[4:43] Then we need to get the user from all of the users. If we open up the project, we can see that we have a data directory and the users.ts. This file contains the list of demo users.

[4:58] We can go back to our API route and import the users. We will do import users from, and then we will jump three times data/users. This makes it simpler, so we don't open any database connections.

[5:14] Now, let's obtain the user from the users, so users.find. We will obtain the ID of the users, and we will return the user whose ID is the same as the same as the provided one. Because the user ID from the query is a string, we need to parse it as an integer.

[5:36] That's how we can obtain the user. If the user does not exist, we need to return result.status of 404, that is the not found status, and then we can return a JSON with the error, "User not found."

[5:52] Otherwise, if the user exists, we need to return result.status of 200, which is the HTTP code for OK, then .JSON and then we'll just return the user. That's it. Our API route is now completed. In order to use it, let's go back to the index page and set the endpoint.

[6:15] The endpoint will be a string template of /API/users and then /the user ID. Now, let's save this and refresh. If we click on the users, we can see that their details are changing. If we open up the inspect element and go to the network tab, we can see that we are sending HTTP requests to our route every time we click on a user.

[6:46] Here's the first one, returns a user and the rest of them. If you go to the headers tab, we can see that our API handler lives in the /API/users. In this case, it's user with the ID of six. If we try to change the ID, and let's use an ID that probably does not exist.

[7:05] Let's see what happens. It says the user is not found or the status code is 404. The preview contains an error saying that the user is not found. This is this case within our API handler.

[7:24] If we change the fetch from GET to a different method, so we can override the method property and set it to POST, and try clicking on a user, we can see that the status code is 405 or the method not allowed, because we are making a post request to our API handler.

[7:49] The preview contains an error saying method not allowed. In our case, this is the line that returns the error. That's how we can build API handlers. Let's recap. Since Next.js is built on top of Node.js, it allows us to define our own API routes. The API routes lived inside of the API folder inside of the page's directory.

[8:15] Everything that lives inside of the API folder is mapped to /API. Those files will not be treated as a page even though they are in the page's directory, but they will be treated as an API endpoint. The API routes are a server-side and will not be bundled with our client-side code.

[8:31] That means we can safely open database connections and use secret environment variables. To make an API route, we needed to export a default async function that accepts the request and the response into its argument and optionally, it can use the NextApiHandler type.

[8:48] The request object contains the method, body, and query properties that we can use to handle the request. Using the request.method, we can check if the method's type is GET, POST, PUT, DELETE and act accordingly.

[9:03] We can use the query property to obtain any dynamic parts, which in this case is the user ID, and we can use the response object to send down the response back to the browser. In this case, we can either return a result, or we can return a suitable error based on the conditions.

https://app.egghead.io/api/v1/lessons/typescript-define-and-use-next-js-api-routes-to-make-server-side-requests/transcript

https://app.egghead.io/api/v1/lessons/typescript-deploy-your-next-js-app-on-vercel/subtitles

Lazar Nikolov: [0:01] Welcome to the last lesson for this course. That is the deploy your Next.js app on Vercel. Technically, Next.js can be deployed anywhere, but the easiest way is to use the Vercel platform, which is created by the people who also created Next.js.

[0:18] Also, Vercel is optimized for Next.js. Out of the box, it applies the following optimizations to your app. Every page can either use Static Generation or Server-Side Rendering.

[0:28] Pages that use Static Generation and assets will automatically be served from Vercel's edge network, which is blazingly fast. Also pages that your Server-Side Rendering and API routes will automatically become isolated serverless functions.

[0:44] This allows page rendering and API request to scale infinitely. Before we begin, make sure you clone this repo, nikolovlazar/deploy-nextjs-on-vercel. This is a demo project that I created just for this purpose.

[0:59] Hit the fork button and make sure you have it in your account. Now, let's login. We're going to use GitHub as the login provider. Now, we're in to create a new project. Let's hit the New Project button.

[1:16] From our import git repository list, we can see the deploy Next.js on Vercel project. Let's hit "Import." As you can see, Vercel automatically detected that this project is a Next.js project. We can change the name if you'd like, but we're going to leave it as Deploy Next.js on Vercel.

[1:35] We can change the root directory in case the Next.js project that you're trying to deploy is not at the root. If we scroll down, we can see two sections. This is the build and output settings.

[1:45] For this project, we use the default settings. If your project has some specific build install and output directory settings, you can overwrite them here.

[1:57] Then, there's the environment variables section, where you can add environment variables that you use in your project. After you set up everything, just hit "Deploy." There we go, Vercel started the build process. This could take a minute.

[2:12] There we go, the project is deployed, and we're welcomed with an amazing congratulations page. If we click on the image, we can see our app deployed and live. That's how easy it is to deploy your Next.js app on Vercel.

https://app.egghead.io/api/v1/lessons/typescript-deploy-your-next-js-app-on-vercel/transcript

Fundamental Next.js API and Patterns

Lazar Nikolov

Prerequisites:

You might also like these resources:

Effectively Build RESTful APIs using Next.js API Routes

ECommerce Product Management & Storefront with GraphCMS, Snipcart, & Next.js

Build a Real-Time Data Syncing Chat Application with Supabase and Next.js

Credits

Course Content

You might also like these resources:

Effectively Build RESTful APIs using Next.js API Routes

ECommerce Product Management & Storefront with GraphCMS, Snipcart, & Next.js

Build a Real-Time Data Syncing Chat Application with Supabase and Next.js