Hello! Today I’m going to discuss Next.js, Facebook’s React framework that has become quite popular this past year. Next is used to implement optimization features in production-ready web applications such as:
•Server-side rendering and/or static generation of pages
•Pre-rendering client-side routes
•Code-splitting
•Bundling and Compiling of code
Let’s jump right in!
Pre-rendering Pages: Server-Side Rendering vs. Static Site Generating
Client-side render speed is affected by an end-user’s browser. This makes it more feasible to (reword) run an initial render of HTML that can be reused as the client sends requests to the server. This is where Next.js comes in. Next.js offers two options for pre-rendering UI; we can use either static generation or server-side rendering as a means to optimize rendering of our pages. Server-Side Rendering renders HTML with every request sent to the server. This is the slower of the two options since a new UI must be rendered for every page. The Next.js documentation recommends use of Static Site Generation (reword), because the server pre-renders dynamic HTML that gets reused as the end user navigates the web application. Only the initial render will generate HTML, making subsequent requests made to the server faster to resolve.
Let’s check this out. Next.js provides a CLI tool for generating production-ready Next applications called Create Next App. From your shell run:
$npx create-next-app <application-name> -e blog-starter
After answering a couple of initialization questions, cd into
the application’s root directory. Here you’ll find a pages directory. Open the file document.js, and you should see the following code:
import Document, { Html, Head, Main, NextScript } from 'next/document'
export default class MyDocument extends Document {
render() {
return (
<Html lang="en">
<Head />
<body>
<Main />
<NextScript />
</body>
</Html>
)
}
}
The _document.js file allows us to modify our html and body tags. We can add components from the next/document module to add attributes to our head tags such as lang=“en”. In the example above, all this file contains is a class component that renders some HTML. You will also find that there is no JavaScript logic beyond the module imports and the class object. The HTML rendered by the _document.js file is rendered on the server, meaning that we won’t find any app logic in this component, nor should we add any. We can add logic to a renderPage function, however, if we plan to implement CSS-in-JS at the application level.
Static Site Generation
Servers usually respond to requests with the appropriate resources. This usually means that multiple requests can lead to re-rendering UI an unnecessary number of times. Next.js gives us the option to pre-render dynamic HTML layouts at build time that gets reused on subsequent requests. This saves time that would be spent re-rendering at every request, making for a more optimal performance. Let’s create a file in our Create-Next-App. Inside the pages directory, create a file and name it About.js, and then populate it with this code:
function About() (
<div>
<h1>About</h1>
</div>
);
export default About;
By default this file will render at build time. API calls or dynamic routing added to this page (using getStaticProps()) will also be pre-rendered. The getStaticProps() method retrieves external data for the server to render, and returns an object of serialized props. This is useful when working with data that gets updated regularly, like blog posts or newly-registered users.
That’s it for Part 1! On the next post I’ll touch a little more on Static Generation and show how we can manage external data when pre-rendering with Next.js.
Top comments (0)