Rendering Strategies in Next.js
Tags: webdev, nextjs
Published: 2022-07-25 11:41:15

Next.js is a framework of recent times. It is built on the shoulders of its predecessors and hence it packs all the best features of them. Due to this Next.js comes with choice of rendering the content. You can either opt in to render a blank html and fill in the components dynamically with javascript, or you can make the server send you packages of content pre-built on the server, ore even better you can ask for a cached copy of the content from a CDN. And the best part is you don't have to subscribe to a particular strategy for the whole application, you can customise and use the strategy best for that page/route for each page/route separately.

In this blogpost I will try to compile my understanding of these various rendering strategies, when is it best to use them and how to implement each one in Next.js. So let's get started.

## CSR: Client Side Rendering

![JavaScript Painting](https://media.giphy.com/media/jUhkz8bRXfFqpwP34k/giphy.gif)

CSR or Client Side Rendering is exactly what it says, the html shell of an application is sent from the server to the client and then the javascript fill int the content as per the route. By default* the Next app uses client side rendering to render the content on the site.

It is ideal to use CSR when the data on the site is purely dynamic i.e. there is nothing certain about what the data will be and the data is being filed dynamically. Some use cases for these will be a payment portal for an e-commerce store, a chat window in a chat app, etc.

You don't have to do anything different than writing normal React components in Next to use CSR, as I said Next uses CSR by default*.

```
export function ReactComponent() {

  useEffect(() => {
    // fetch data here
  }, [])

  return (
    // render the component
  )
}
```

**PROS**: Your pages are dynamic and no recurrent server calls are made.

**CONS**: If the data get huge there will likely be lags and loading states (Bad UX) and there is nothing for the browser bots to read (Bad SEO).

## SSR: Server Side Rendering

![Browser bots Happy](https://media.giphy.com/media/fepKnAxq8tjIGTcxny/giphy.gif)

When you use SSR or Server Side Rendering, Next get the data require for the path on the server itself and builds the page for that route on the server and then sends the prebuilt page to the client and hence, providing page fully loaded with content from the very start.

SSR is ideally used where the you want the used to not notice any lag in the page loading and the data coming in to the page hence improving the user experience. It can also be used where the the there is less need of the page being more purely dynamic and more need of improving the SEO of the site.

In Next.js you can simply make a page use SSR rendering strategy by adding in a method called `getServerSideProps()` and fetching all the dependent data in this method and export props from it and consuming the props in the React component for the page.

```
export async function getServerSideProps() {

  // fetch data here

  return {
    props: {
      data,
    }
  }
}

export function ReactComponent(props) {

  return (
    // render the component
  )
}
```

**PROS**: Better SEO, Better User Experience

**CONS**: More server calls

## SSG: Static Site Generation

![CDN](https://media.giphy.com/media/2dbnhlCH2JhwdI2gHp/giphy.gif)

This is the best (objectively 😁), SSG or Static Site Generation is when the pages for the routes are built and stored to a CDN, so whenever the route is hit the page is server readily built from the CDN. (Just WOW)

This strategy is best for the cases where the data on the page is not changes frequently, such as blogs and landing pages. You can SSG for changing data too but it is not ideal.

In Next.js to implement a page/route as statically generated page, you just need to add a additional method provided by Next called `getStaticProps()`, fetch data here, export it as props and then consume it in the React component for the page/route.

The tricky part with this is when you need to SSG dynamic routes. What you need to do in these situations is add another method provided by next called `getStaticPaths()`, return all the possible sub-routes from here and consume these as the ids in the `getStaticProps()` method.

```
export async function getStaticPaths() {

  // get data here

  return {
    params: {
      id: *ID for this page*,
    }
  }
}

export async function getStaticProps() {

  // fetch data here

  return {
    props: {
      data,
    }
  }
}

export function ReactComponent(props) {

  return (
    // render the component
  )
}
```

**PROS**: SuperFast, No Server calls, directly server from CDN

**CONS**: Not good with frequently changing data

## Conclusion
All these rendering strategies are different tools and each of these tools is suited for different task and accomplish different things. The great thing is in Next.js you can configure for each page/route to which strategy to use for that particular page.

_* Well Next.js don't use CSR all the way. It will serve server render pages for the path and then CSR takes over._