Create A Nextjs App

Posted on  by admin

Next.js is an open-source JavaScript framework created by Vercel to enhance React applications with features such as Server-Side Rendering and Static Site Generation.

Traditionally, React is used to create Single-Page Applications (SPAs) whose contents are rendered on the client side.

Next.js extends this by allowing developers to create applications that can perform server-side actions, pre-fetch routes, and has support for TypeScript.

On top of that - it doesn't require any extra configuration by default! In this guide, we'll take a look at the pertinent features and workings of Next.js.

What is Create-React-App

  • To solidify the new knowledge, we'll build a full multi-page weather application, that talks to external APIs and allows a user to record given states.
  • Note: The complete code for this application can be found on GitHub.

Create next.js app

The easiest way to create a new Next.js application is by using the create-next-app CLI tool. You can install it via npm:. Once installed, you can initialize a new Next.js application by calling the tool and supplying a name for your project:.

Note: If you don't already have create-next-app installed - npx will prompt you to install it automatically.

Once the tool finished initializing a skeleton project, let's move to the directory and take a peek inside:.

  • The standard package.json, package-lock.json and node_modules are there, however, we've also got the /pages, /public and /styles directories, as well as a next.config.js file!
  • Let's take a look at what these are. Next.js is ultimately an extension for React, and it does introduce a couple of new things that make React application development simpler and faster - starting with Next.js pages.
  • Next.js makes creating multi-page applications with React ridiculously easy with its default file-system-based router.

You don't need to install any additional packages, such as react-router-dom, or configure a router at all. All Next.js projects include a default /pages directory, which is the home of all of the React components you'll be using.

First ways

For each component - a router will serve a page based on that component. A React component is a page in Next's eyes, and is served automatically on the path corresponding to its filename.

For instance, suppose we create a component, contact.js, within the /pages directory:.

The file-system-based router that Next.js employs will make this page accessible under the /contact route!

  • The only exception to this rule is the index.js page, which isn't located under /index route, but rather, it's served at /.
  • Additionally, you can nest routes with Next.js, so you can easily create a /weather/berlin dynamically by creating /weather folder, and a dynamic [city].js component to act as the page.
  • Note: For dynamic routes, you need to name the file in a set of square brackets. Without them, it's a static literal string, and it will be parsed as such.
  • city.js would resolve to the /weather/city route, and wouldn't match for anything else. On the other hand [city.js] would match for /weather/berlin, /weather/london, /weather/lagos, etc.

The component can be used to navigate between pages in your apps. Assuming our project page structure has several pages under the /pages directory:.

  • The component's href attribute can be used to point to the relative path of each page, starting at the /pages directory:. Naturally, if you have a nested hierarchy of files, you can link to nested pages as well:.
  • The component can also pre-fetch pages! Once a page has been loaded, and there are multiple links to other pages - if you know that a certain page is to be visited often, or would like to make sure that the page is loaded as soon as possible (without impacting the initial page), you can pre-fetch the page associated with a to make the transition faster the smoother!

In fact, Next.js prefetches all pages by default. To that end, if you'd like to speed up a transition to a certain page, you set the prefetch attribute to false for other pages. For instance, it's conceivable that in a weather app, people are more likely to navigate to the /weather route from the home page, rather than /about.

There's no need to pre-fetch the about.js page/component, since you'd be burdening the server further for a page that isn't too likely to be clicked. On the other hand - weather.js is most likely to be the next route people visit, so you can shave off some time in the transition by pre-fetching it:.

Some other attributes include the scroll attribute (which defaults to true), which navigates the user to the top of the page when they re-route themselves with a .

This is a very sensible default, though you might want to turn it off for a more specific effect you'd like to achieve.

  • Another attribute worth noting is the replace attribute, which defaults to false. If set to true, it'll replace the latest entry in the history stack, instead of pushing a new one, when you navigate to a new page/route with a .
  • Speaking of pre-fetching and pre-rendering pages - this feature of Next.js is one of the more pertinent ones.
  • Again, by default, Next.js will pre-fetch all of the pages that you link to, allowing for smooth, quick transitions between them.

For each page, you may choose between Server-Side Rendering or Static Generation and which technique is used depends on the functions you use to fetch data.

  • You're not forced to adhere to one of these techniques for the entirety of the application!
  • Choosing between SSR and SG is a question of where you'd like to place the load, and both techniques pre-render pages, just in a different way.
  • If you render your pages on the server-end, they'll be rendered on each request, using your server's resources, and sent to the end-user.

If you statically generate a page, it's generated once and is reusable after build time. Note: Generally speaking, you'll want to use Static Generation whenever there's no need to use Server-Side Rendering since the page can then be cached and reused, saving valuable computation.


Whenever components on pages are frequent, Server-Side Rendering is required, and the page is rendered when requested with new data (some of which may depend on the request itself).

You may also decide to let some pages or elements on the page to be rendered via Client-Side Rendering which places the load on the end-user's machine, but you have no guarantees nor control over their resources, so typically, you want to avoid any intensive computation on their end.