*Hello, my name is Igor and if by chance, you enjoy what I write, you may also like what I have to say on [my Twitter profile](https://www.twitter.com/igorasilveira), come and say 'Hi! 👋'.*

This article is part of an entire Next.js series of articles I am putting together to help you become a Next.js pro and build blazing-fast React apps.

💡 If you don’t want to miss out on any of the tutorials, signup for my newsletter by [clicking here](https://www.getrevue.co/profile/igorasilveira) or head over to [DailyDev.io](https://dailydev.io/) for more.

On this issue, we will be talking about Next.js **Server-Side Rendering**, complementing the last video on the **pre-rendering** topic.

<aside>
  💡 You can find the source code for this project <a href="https://github.com/igorasilveira/blog-examples/tree/main/nextjs-server-side-rendering">here</a>.

</aside>

So let’s get started!

Be sure to check out my previous articles on *Next.js pages*, *Dynamic Routing,* and *Static Site Generation* before continuing to better understand what we will be doing here.

## Quick Recap

The last time we were here, we introduced the concept of **pre-rendering**, the default method that Next.js uses to render its pages, resulting in better performance and less effort for the client, by serving the client with a pre-built HTML file bundled with the necessary JavaScript file to make it work.

![Untitled.001.jpeg](https://admitted-shamrock-c0f.notion.site/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2F44e3ff0c-b649-4854-a1f1-a0cdcdc41d83%2FUntitled.001.jpeg?table=block&id=38cbe8df-cfa2-4b9a-ac1f-941124568345&spaceId=a1132038-30f4-4c02-8dbb-44ea7cf0c715&width=2000&userId=&cache=v2)

We discussed that Next.js presented two main ways of pre-rendering: **Static Site Generation** and **Server-Side Rendering**. That time, we covered the former and updated our upcoming dog-searching app to reap the benefits of that Next.js feature, and on this one, we will be learning something new.

## Server-Side Rendering

**Server-Side Rendering** works on the same basis as **Static Site Generation** where the goal is to serve the client with a pre-built static HTML page that the server has pre-rendered and that is then hydrated by the bundled JavaScript file, restoring the page to its true interactive glory.

The main difference to retain between these two **pre-rendering** methods that Next.js ships with, is **when** the page’s HTML is pre-rendered.

**Static Site-**generated pages are pre-rendered at **build time** when the `next build` command is run. It is a case of generating and forgetting about them until a new build is necessary to reflect new changes.

On **Server-Side**-generated pages, however, the page’s HTML is generated on **each request** to the server. This means that the same page is rendered multiple times along the application’s lifetime. As many as it is requested (unless we use *caching*, more on that later).

![Pre-rendering.001.jpeg](https://admitted-shamrock-c0f.notion.site/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2Fe127c7a2-1ba4-45a1-a245-b2bf8a931c5e%2FPre-rendering.001.jpeg?table=block&id=f44377e5-eb5d-42ab-a830-e7eea382131f&spaceId=a1132038-30f4-4c02-8dbb-44ea7cf0c715&width=2000&userId=&cache=v2)

As you can see, server-side rendered pages will be less performant than statically generated ones and cannot be stored on a CDN for faster global access.

However, sometimes **Server-Side Rendering** may be the only option. The main reason you might be looking into using **Server-Side Rendering** over **Static Site Generation** when creating a page is if that page needs to pre-render frequently updated data that must be fetched from some external data source and can’t, therefore, be statically generated at build time as it needs to always be up-to-date.

### How to Use It

Unless we specify that a page is to be either server-side rendered or statically rendered with data (check the previous article), Next.js won’t be able to tell the difference.

To do this, Next.js allows us to define specific **methods** within our page’s components that it will then evaluate and assess whether each page is to be pre-rendered at build time or on each request. 

Previously, we discussed the **Static Site Generation**-specific methods and **Server-Side Rendering** is no different.

To use **Server-Side Rendering** for a page, we export an `async` function named `getServerSideProps` from our page’s **React Component**. This is the function that the Next.js server will call on every request to this page.

This function will feed any data that we wish into our page component through its `props`, by having a very specific return type.

```tsx
function Doggo({ data }) {
  // Render data...
}

// This gets called on every request
export async function getServerSideProps() {
  // Fetch data from external data source
  const res = await fetch(`https://.../data`)
  const data = await res.json()

  // Pass data to the page via props
  return { props: { data } }
}

export default Doggo
```

And just like that, our page became server-side rendered and will always be up-to-date every time it is requested! 😎

## Updating our Dog App

Now let’s create a server-side rendered page within our Doggo App to see it in action.

For the purpose of this tutorial, we will create a page that will display a dog carousel whose data will be coming from the server every time we request that page.

<aside>
💡 NOTE: If you haven’t been following the creation of the Doggo App, you can checkout <a href="https://github.com/igorasilveira/blog-examples/tree/main/nextjs-static-generation">this GitHub repository</a> and modify it.

</aside>

### Creating our New Page

Let’s create a new file under the `/pages/dogs` directory called `carousel.tsx`.

Export a new **React Component** called `Carousel` that will receive a `data` object as component `props` that are typed with an `array` of our Dog `interface` created in the last article (check `/definitions/dogs.d.ts`).

Render some HTML in it and your component should look something like this:

```tsx
import type { NextPage } from "next";
import Link from "next/link";

const Carousel: NextPage<{ data: Dog[] }> = ({ data }) => {
  return (
    <div>
      <main>
        <h1>Carousel</h1>
        {/* Create carousel here */}
        <p style={{ color: "#0070f3" }}>
          <Link href="/">Back to Index</Link>
        </p>
      </main>
    </div>
  );
};

export default Carousel;
```

### Making it Server-Side Rendered

Now let’s add the magical function that makes this a server-side rendered page, the `getServerSideProps` function.

This function will fetch all dogs in our in-memory database that we created as a TypeScript file exporting an `array` (check `/db/dogs.ts`, we also added a few more entries for this tutorial), and return them as a randomly sorted list so that our newly created component can use it to create a “frequently” updated carousel.

<aside>
💡 Keep in mind that in a real-world scenario this would be an external API call that would probably handle more logic to generate the required data. But for the purpose of this tutorial, we will be simplifying the process in order to focus on the subject at hand, server-side rendering.

</aside>

Our function should be something similar to this:

```tsx
export const getServerSideProps: GetServerSideProps = async () => {
  // get a list of all dogs randomly sorted and limited to 2
  const data = [...dogs].sort(() => Math.random() - 0.5).slice(0, 2);

  return { props: { data } };
}
```

### Rendering the Data

Now that we have our component receiving data, we can take it and do whatever we please with it.

I’ll be creating a two-column `grid` and inside it, we go through each item on our `data` prop (that we know is a `Dog`) and we render their name and description on the screen. Of course, we also add some CSS just so that this doesn’t become a hot mess of HTML. 😉

Maybe something like this:

```tsx
const Carousel: NextPage<{ data: Dog[] }> = ({ data }) => {
  return (
    <div>
      <main>
        <h1>Carousel</h1>

        <div
          style={{
            width: "50%",
            display: "grid",
            gridTemplateColumns: "repeat(2, 1fr)",
          }}
        >
          {data.map((dog) => (
            <Link href={`/dogs/${dog.id}`} key={dog.id}>
              <div style={{
                border: "1px solid #ccc",
                cursor: "pointer",
              }}>
                <h2>{dog.name}</h2>
                <p>{dog.description}</p>
              </div>
            </Link>
          ))}
        </div>
        {/* For every dog in data array, display their name and description */}

        <p style={{ color: "#0070f3" }}>
          <Link href="/">Back to Index</Link>
        </p>
      </main>
    </div>
  );
};
```

### Final Result

So by the end, the page that can be found under `/dogs/carousel` should look something like this and be updated each time we request it with data fetched by the server. Cool! 😎

![ezgif.com-gif-maker (5).gif](https://admitted-shamrock-c0f.notion.site/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2Ffbd48954-e102-4ea2-a60d-23bd5d4d9d93%2Fezgif.com-gif-maker_(5).gif?table=block&id=0348217a-5fa3-448a-a498-b27de1cc8322&spaceId=a1132038-30f4-4c02-8dbb-44ea7cf0c715&userId=&cache=v2)

## Final Remarks

To experience the differences between **Static Site Generation** and **Server-Side Rendering**, don’t forget to run the **build** command (`npm run build`) followed by **serving** (`npm run start`) the generated files. This is how the pages would be served in a production environment and cached by some CDN.

Running the project in `npm run dev` mode will always build all pages on each request, running all specific pre-rendering functions on all requests.

![Screenshot 2022-06-23 at 08.00.03.png](https://admitted-shamrock-c0f.notion.site/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2Fe8a68fee-334d-483a-aa0f-012150946a8f%2FScreenshot_2022-06-23_at_08.00.03.png?table=block&id=a3e23f0f-6a6f-458c-95ca-9b0ef8688a99&spaceId=a1132038-30f4-4c02-8dbb-44ea7cf0c715&width=1830&userId=&cache=v2)

Notice how Next.js detected which pages were static or server-side rendered.

If you run into any trouble feel free to reach out to me on [Twitter](https://twitter.com/igorasilveira), my DMs are always open.

**Next Steps:** Keep an eye out for my following Next.js tutorials where we will go over much more in Next.js territory! If you don’t want to miss out on any of the tutorials, signup for my newsletter by [clicking here](https://www.getrevue.co/profile/igorasilveira).

<p><em>Hello, my name is Igor and if by chance, you enjoy what I write, you may also like what I have to say on <a href="https://www.twitter.com/igorasilveira">my Twitter profile</a>, come and say 'Hi! 👋'.</em></p>
<p>This article is part of an entire Next.js series of articles I am putting together to help you become a Next.js pro and build blazing-fast React apps.</p>
<p>💡 If you don’t want to miss out on any of the tutorials, signup for my newsletter by <a href="https://www.getrevue.co/profile/igorasilveira">clicking here</a> or head over to <a href="https://dailydev.io/">DailyDev.io</a> for more.</p>
<p>On this issue, we will be talking about Next.js <strong>Server-Side Rendering</strong>, complementing the last video on the <strong>pre-rendering</strong> topic.</p>
<aside>
  💡 You can find the source code for this project <a href="https://github.com/igorasilveira/blog-examples/tree/main/nextjs-server-side-rendering">here</a>.
</aside>
<p>So let’s get started!</p>
<p>Be sure to check out my previous articles on <em>Next.js pages</em>, <em>Dynamic Routing,</em> and <em>Static Site Generation</em> before continuing to better understand what we will be doing here.</p>
<h2>Quick Recap</h2>
<p>The last time we were here, we introduced the concept of <strong>pre-rendering</strong>, the default method that Next.js uses to render its pages, resulting in better performance and less effort for the client, by serving the client with a pre-built HTML file bundled with the necessary JavaScript file to make it work.</p>
<p><img src="https://admitted-shamrock-c0f.notion.site/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2F44e3ff0c-b649-4854-a1f1-a0cdcdc41d83%2FUntitled.001.jpeg?table=block&#x26;id=38cbe8df-cfa2-4b9a-ac1f-941124568345&#x26;spaceId=a1132038-30f4-4c02-8dbb-44ea7cf0c715&#x26;width=2000&#x26;userId=&#x26;cache=v2" alt="Untitled.001.jpeg"></p>
<p>We discussed that Next.js presented two main ways of pre-rendering: <strong>Static Site Generation</strong> and <strong>Server-Side Rendering</strong>. That time, we covered the former and updated our upcoming dog-searching app to reap the benefits of that Next.js feature, and on this one, we will be learning something new.</p>
<h2>Server-Side Rendering</h2>
<p><strong>Server-Side Rendering</strong> works on the same basis as <strong>Static Site Generation</strong> where the goal is to serve the client with a pre-built static HTML page that the server has pre-rendered and that is then hydrated by the bundled JavaScript file, restoring the page to its true interactive glory.</p>
<p>The main difference to retain between these two <strong>pre-rendering</strong> methods that Next.js ships with, is <strong>when</strong> the page’s HTML is pre-rendered.</p>
<p><strong>Static Site-</strong>generated pages are pre-rendered at <strong>build time</strong> when the <code>next build</code> command is run. It is a case of generating and forgetting about them until a new build is necessary to reflect new changes.</p>
<p>On <strong>Server-Side</strong>-generated pages, however, the page’s HTML is generated on <strong>each request</strong> to the server. This means that the same page is rendered multiple times along the application’s lifetime. As many as it is requested (unless we use <em>caching</em>, more on that later).</p>
<p><img src="https://admitted-shamrock-c0f.notion.site/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2Fe127c7a2-1ba4-45a1-a245-b2bf8a931c5e%2FPre-rendering.001.jpeg?table=block&#x26;id=f44377e5-eb5d-42ab-a830-e7eea382131f&#x26;spaceId=a1132038-30f4-4c02-8dbb-44ea7cf0c715&#x26;width=2000&#x26;userId=&#x26;cache=v2" alt="Pre-rendering.001.jpeg"></p>
<p>As you can see, server-side rendered pages will be less performant than statically generated ones and cannot be stored on a CDN for faster global access.</p>
<p>However, sometimes <strong>Server-Side Rendering</strong> may be the only option. The main reason you might be looking into using <strong>Server-Side Rendering</strong> over <strong>Static Site Generation</strong> when creating a page is if that page needs to pre-render frequently updated data that must be fetched from some external data source and can’t, therefore, be statically generated at build time as it needs to always be up-to-date.</p>
<h3>How to Use It</h3>
<p>Unless we specify that a page is to be either server-side rendered or statically rendered with data (check the previous article), Next.js won’t be able to tell the difference.</p>
<p>To do this, Next.js allows us to define specific <strong>methods</strong> within our page’s components that it will then evaluate and assess whether each page is to be pre-rendered at build time or on each request. </p>
<p>Previously, we discussed the <strong>Static Site Generation</strong>-specific methods and <strong>Server-Side Rendering</strong> is no different.</p>
<p>To use <strong>Server-Side Rendering</strong> for a page, we export an <code>async</code> function named <code>getServerSideProps</code> from our page’s <strong>React Component</strong>. This is the function that the Next.js server will call on every request to this page.</p>
<p>This function will feed any data that we wish into our page component through its <code>props</code>, by having a very specific return type.</p>
<pre><code class="language-tsx">function Doggo({ data }) {
  // Render data...
}

// This gets called on every request
export async function getServerSideProps() {
  // Fetch data from external data source
  const res = await fetch(`https://.../data`)
  const data = await res.json()

  // Pass data to the page via props
  return { props: { data } }
}

export default Doggo
</code></pre>
<p>And just like that, our page became server-side rendered and will always be up-to-date every time it is requested! 😎</p>
<h2>Updating our Dog App</h2>
<p>Now let’s create a server-side rendered page within our Doggo App to see it in action.</p>
<p>For the purpose of this tutorial, we will create a page that will display a dog carousel whose data will be coming from the server every time we request that page.</p>
<aside>
💡 NOTE: If you haven’t been following the creation of the Doggo App, you can checkout <a href="https://github.com/igorasilveira/blog-examples/tree/main/nextjs-static-generation">this GitHub repository</a> and modify it.
</aside>
<h3>Creating our New Page</h3>
<p>Let’s create a new file under the <code>/pages/dogs</code> directory called <code>carousel.tsx</code>.</p>
<p>Export a new <strong>React Component</strong> called <code>Carousel</code> that will receive a <code>data</code> object as component <code>props</code> that are typed with an <code>array</code> of our Dog <code>interface</code> created in the last article (check <code>/definitions/dogs.d.ts</code>).</p>
<p>Render some HTML in it and your component should look something like this:</p>
<pre><code class="language-tsx">import type { NextPage } from "next";
import Link from "next/link";

const Carousel: NextPage&#x3C;{ data: Dog[] }> = ({ data }) => {
  return (
    &#x3C;div>
      &#x3C;main>
        &#x3C;h1>Carousel&#x3C;/h1>
        {/* Create carousel here */}
        &#x3C;p style={{ color: "#0070f3" }}>
          &#x3C;Link href="/">Back to Index&#x3C;/Link>
        &#x3C;/p>
      &#x3C;/main>
    &#x3C;/div>
  );
};

export default Carousel;
</code></pre>
<h3>Making it Server-Side Rendered</h3>
<p>Now let’s add the magical function that makes this a server-side rendered page, the <code>getServerSideProps</code> function.</p>
<p>This function will fetch all dogs in our in-memory database that we created as a TypeScript file exporting an <code>array</code> (check <code>/db/dogs.ts</code>, we also added a few more entries for this tutorial), and return them as a randomly sorted list so that our newly created component can use it to create a “frequently” updated carousel.</p>
<aside>
💡 Keep in mind that in a real-world scenario this would be an external API call that would probably handle more logic to generate the required data. But for the purpose of this tutorial, we will be simplifying the process in order to focus on the subject at hand, server-side rendering.
</aside>
<p>Our function should be something similar to this:</p>
<pre><code class="language-tsx">export const getServerSideProps: GetServerSideProps = async () => {
  // get a list of all dogs randomly sorted and limited to 2
  const data = [...dogs].sort(() => Math.random() - 0.5).slice(0, 2);

  return { props: { data } };
}
</code></pre>
<h3>Rendering the Data</h3>
<p>Now that we have our component receiving data, we can take it and do whatever we please with it.</p>
<p>I’ll be creating a two-column <code>grid</code> and inside it, we go through each item on our <code>data</code> prop (that we know is a <code>Dog</code>) and we render their name and description on the screen. Of course, we also add some CSS just so that this doesn’t become a hot mess of HTML. 😉</p>
<p>Maybe something like this:</p>
<pre><code class="language-tsx">const Carousel: NextPage&#x3C;{ data: Dog[] }> = ({ data }) => {
  return (
    &#x3C;div>
      &#x3C;main>
        &#x3C;h1>Carousel&#x3C;/h1>

        &#x3C;div
          style={{
            width: "50%",
            display: "grid",
            gridTemplateColumns: "repeat(2, 1fr)",
          }}
        >
          {data.map((dog) => (
            &#x3C;Link href={`/dogs/${dog.id}`} key={dog.id}>
              &#x3C;div style={{
                border: "1px solid #ccc",
                cursor: "pointer",
              }}>
                &#x3C;h2>{dog.name}&#x3C;/h2>
                &#x3C;p>{dog.description}&#x3C;/p>
              &#x3C;/div>
            &#x3C;/Link>
          ))}
        &#x3C;/div>
        {/* For every dog in data array, display their name and description */}

        &#x3C;p style={{ color: "#0070f3" }}>
          &#x3C;Link href="/">Back to Index&#x3C;/Link>
        &#x3C;/p>
      &#x3C;/main>
    &#x3C;/div>
  );
};
</code></pre>
<h3>Final Result</h3>
<p>So by the end, the page that can be found under <code>/dogs/carousel</code> should look something like this and be updated each time we request it with data fetched by the server. Cool! 😎</p>
<p><img src="https://admitted-shamrock-c0f.notion.site/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2Ffbd48954-e102-4ea2-a60d-23bd5d4d9d93%2Fezgif.com-gif-maker_(5).gif?table=block&#x26;id=0348217a-5fa3-448a-a498-b27de1cc8322&#x26;spaceId=a1132038-30f4-4c02-8dbb-44ea7cf0c715&#x26;userId=&#x26;cache=v2" alt="ezgif.com-gif-maker (5).gif"></p>
<h2>Final Remarks</h2>
<p>To experience the differences between <strong>Static Site Generation</strong> and <strong>Server-Side Rendering</strong>, don’t forget to run the <strong>build</strong> command (<code>npm run build</code>) followed by <strong>serving</strong> (<code>npm run start</code>) the generated files. This is how the pages would be served in a production environment and cached by some CDN.</p>
<p>Running the project in <code>npm run dev</code> mode will always build all pages on each request, running all specific pre-rendering functions on all requests.</p>
<p><img src="https://admitted-shamrock-c0f.notion.site/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2Fe8a68fee-334d-483a-aa0f-012150946a8f%2FScreenshot_2022-06-23_at_08.00.03.png?table=block&#x26;id=a3e23f0f-6a6f-458c-95ca-9b0ef8688a99&#x26;spaceId=a1132038-30f4-4c02-8dbb-44ea7cf0c715&#x26;width=1830&#x26;userId=&#x26;cache=v2" alt="Screenshot 2022-06-23 at 08.00.03.png"></p>
<p>Notice how Next.js detected which pages were static or server-side rendered.</p>
<p>If you run into any trouble feel free to reach out to me on <a href="https://twitter.com/igorasilveira">Twitter</a>, my DMs are always open.</p>
<p><strong>Next Steps:</strong> Keep an eye out for my following Next.js tutorials where we will go over much more in Next.js territory! If you don’t want to miss out on any of the tutorials, signup for my newsletter by <a href="https://www.getrevue.co/profile/igorasilveira">clicking here</a>.</p>


On this issue, we will be talking about Next.js Server-Side Rendering, enabling high-performant websites by pre-rendering HTML instead of having it all done by client-side JavaScript.

Next.js Server-Side Rendering Practical Example

NextJS

Web Dev

*Hello, my name is Igor and if by chance, you enjoy what I write, you may also like what I have to say on [my Twitter profile](https://www.twitter.com/igorasilveira), come and say 'Hi! 👋'.*

This article is part of an entire Next.js series of articles that I am putting together to help you become a Next.js pro and start building blazing fast React apps, either static, client-rendered, server-rendered or a mix of both (but we will get to that later).

💡 If you don’t want to miss out on any of the tutorials, signup for my newsletter by [clicking here](https://www.getrevue.co/profile/igorasilveira) or head over to [DailyDev.io](https://dailydev.io/) for more.

On this issue, we will be learning about how Next.js makes it incredibly easy to navigate between pages within our application using *prefetching* ensuring our app is fast and secure.

<aside>
💡 You can find the source code for this project <a href="https://github.com/igorasilveira/blog-examples/tree/main/nextjs-basic-routing">here</a>.
</aside>

So let’s get started!

### Pre-requisites

- Node ≥ 12
- React Basics

## Creating a Next.js App

To kick this off, we need our very own freshly-built Next.js which we can get by simply running this command in the directory you wish to store all of your awesome Next.js projects.

```bash
npx create-next-app nextjs-basic-routing --use-npm --typescript
```

*A breakdown of what we just did:*

- `npx` - is a command-line interface tool that makes it easy to execute npm packages without actually installing them on your own machine.
- `create-next-app` - our best friend, will scaffold a perfectly balanced Next.js app for you.
- `nextjs-basic-routing` - this is the name I decided to give my project, feel free to mix it up a bit.
- `--use-npm` - this flag specifies that we want to use NPM as our dependency manager.
- `--typescript` - this flag tells the scaffolding tool that we want to generate a TypeScript project and it initializes all required dependencies (this is more of a personal preference of mine - ❤️ TypeScript).

## Running our App

Our Next.js project has been created and all dependencies automatically installed. We can now run it and see our app come to life!

In the same terminal we used to scaffold our project, we now `cd` into our project folder ie. `cd nextjs-basic-routing` and we run the following command to start our project in **development mode**.

```bash
npm run dev
```

After a couple of seconds, your Next.js app server is launched (hopefully with success) and you can now navigate to `http://localhost:3000` and reveal your Next.js app, similar to the one below.

![Screenshot 2022-02-17 at 07.48.19.png](https://admitted-shamrock-c0f.notion.site/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2Fd173ed60-2ba7-489d-8438-7550084f648a%2FScreenshot_2022-02-17_at_07.48.19.png?table=block&id=53b58050-c151-46dc-9da1-7148d5817894&spaceId=a1132038-30f4-4c02-8dbb-44ea7cf0c715&width=2000&userId=&cache=v2)

We are now open for business! 🥳

## Next.js Routing

Now that we have our application up and running, let’s start looking at how Next.js beautifully handles its pages and routing, starting by creating our very own new page.

### Pages

In Next.js, every page is a React Component that is exported from a file that lives in the `/pages` directory at the root of your project. The name of the file dictates the route it will be associated with, including the folder(s), if any, that the React Component is living in. There is a special filename that is associated with the **root** of your app, and that is the `index.tsx` file already came included with our initial scaffolding.

- `/pages/index.tsx` maps to the `/` route (our homepage)
- `/pages/dogs/a-doggo.tsx` maps to the `/dogs/a-doggo.tsx` route.

### Creating a new Page

So if we were to create that doggo page mapped to that specific route, I’d need to create a new folder within `/pages` and, inside that new folder, export a new React Component from a file named `a-doggo.tsx`. Your file tree would look something like this:

![Screenshot 2022-02-18 at 07.03.33.png](https://admitted-shamrock-c0f.notion.site/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2Fde90c9d7-a2b4-47f1-ba74-57d2f642280f%2FScreenshot_2022-02-18_at_07.03.33.png?table=block&id=cb9d4ba9-6acb-4cb4-b1dd-75e77e56321f&spaceId=a1132038-30f4-4c02-8dbb-44ea7cf0c715&width=680&userId=&cache=v2)

(Don’t mind the `_app.tsx` file, for now, that is a special file)

The contents of the new file can be anything you wish, as long as it exports a default React Component that renders some JSX that Next.js can then render as HTML. For example, this is the code of my React Component.

```tsx
import type { NextPage } from 'next'
import Head from 'next/head'
import Image from 'next/image'

const Doggo: NextPage = () => {
  return (
    <div>
      <Head>
        <title>A Doggo</title>
      </Head>

      <main>
        <h1>
          This is a Doggo.
        </h1>

        <Image alt="This is a doggo" src='https://loremflickr.com/520/520/dog' width={520} height={520}/>
      </main>
    </div>
  )
}

export default Doggo
```

I wanted to have a random image of a doggo, so I used [https://loremflickr.com](https://loremflickr.com/), a nice tool for randomly generated assets. In order for this to work with Next.js, we need to add this domain as an image provider in the `next.config.js` file as below. 

(**NOTE:** this is optional and you can make your React Component show whatever you want and not use this image generator)

```jsx
const nextConfig = {
  reactStrictMode: true,
  images: {
    domains: [
      "loremflickr.com"  // <- added this
    ]
  }
}

module.exports = nextConfig
```

If we now run our server and navigate to `http://localhost:3000/dogs/a-doggo`, there will be a random image of a doggo for us to contemplate. 🐶

![Screenshot 2022-02-18 at 07.29.49.png](https://admitted-shamrock-c0f.notion.site/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2Fc8f8c7c2-2c63-4919-91d9-c578097281ef%2FScreenshot_2022-02-18_at_07.29.49.png?table=block&id=d3940ba5-5c3b-4a47-81b2-f68ed839b28b&spaceId=a1132038-30f4-4c02-8dbb-44ea7cf0c715&width=2000&userId=&cache=v2)

### Navigating Static Routes

Our application now has two pages, and to navigate between them we have been manually changing our URL in the address bar. Let’s change that!

Normally, we link between pages on our own or external website using the `<a>` HTML tag. But Next.js builds on top of that. You can use the `Link` Component to wrap the `<a>` tag, allowing you to do **client-side navigation** to a different page in the application.

**Client-side navigation** means that the page transition happens using *JavaScript*, which is faster than the default browser navigation methods.

Another great benefit of using Next.js `Link` Component is that pages containing one or more `Link` Components will **prefetch** the code for the linked page in the background as soon as the `Link` becomes visible in the viewport. This allows for a faster initial page render as Next.js will only load the code for the page you requested and only load other linked pages when the `Link` Component is visible, and it does it in the background, not impacting the overall user experience and making the navigation extremely fast for a client-side application.

But how do we use it then? Well, it is pretty straightforward as using a normal `<a>` HTML tag would be. So let’s include a `Link` on our Homepage to go to our *doggo* page and another to get back home.

Replace your `/pages/index.tsx` code with the following:

```jsx
import type { NextPage } from 'next'
import Head from 'next/head'
import Image from 'next/image'
import Link from 'next/link'
import styles from '../styles/Home.module.css'

const Home: NextPage = () => {
  return (
    <div className={styles.container}>
      <Head>
        <title>Create Next App</title>
        <meta name="description" content="Generated by create next app" />
        <link rel="icon" href="/favicon.ico" />
      </Head>

      <main className={styles.main}>
        <h1 className={styles.title}>
          Welcome to <a href="https://nextjs.org">Next.js!</a>
        </h1>

        <p className={styles.description}>
          Let&apos;s check our <Link href="dogs/a-doggo">doggo</Link>.
        </p>

      </main>

      <footer className={styles.footer}>
        <a
          href="https://vercel.com?utm_source=create-next-app&utm_medium=default-template&utm_campaign=create-next-app"
          target="_blank"
          rel="noopener noreferrer"
        >
          Powered by{' '}
          <span className={styles.logo}>
            <Image src="/vercel.svg" alt="Vercel Logo" width={72} height={16} />
          </span>
        </a>
      </footer>
    </div>
  )
}

export default Home
```

In your `/pages/a-doggo.tsx` replace your code with this one where we added a styled paragraph linking to our home page.

```jsx
import type { NextPage } from 'next'
import Head from 'next/head'
import Image from 'next/image'
import Link from 'next/link'

const Doggo: NextPage = () => {
  return (
    <div>
      <Head>
        <title>A Doggo</title>
      </Head>

      <main>
        <h1>
          This is a Doggo.
        </h1>

        <Image alt="This is a doggo" src='https://loremflickr.com/520/520/dog' width={520} height={520}/>
        <p style={{color: "#0070f3"}}><Link href="/">Back Home</Link></p>
      </main>
    </div>
  )
}

export default Doggo
```

And now we can easily navigate through our application’s pages 😎

![Screen Recording 2022-02-19 at 08.34.36.gif](https://admitted-shamrock-c0f.notion.site/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2Fb9ca052a-8507-477c-b9f9-7bbb1dc74340%2FScreen_Recording_2022-02-19_at_08.34.36.gif?table=block&id=cc5f76c6-662b-4ca7-bbe2-47e533efcdb1&spaceId=a1132038-30f4-4c02-8dbb-44ea7cf0c715&userId=&cache=v2)

## Final Remarks

Now that you have a working Next.js app up and running, don't stop there. As a good exercise, go ahead and create more pages for your application (*ie. About Us, Contacts*) and more doggos. If you run into any trouble feel free to reach out to me on [Twitter](https://twitter.com/igorasilveira), my DMs are always open.

**Next Steps:** Keep an eye out for my following Next.js tutorials where we will go over *Dynamic Routes* and much more! If you don’t want to miss out on any of the tutorials, signup for my newsletter by [clicking here](https://www.getrevue.co/profile/igorasilveira).

<p><em>Hello, my name is Igor and if by chance, you enjoy what I write, you may also like what I have to say on <a href="https://www.twitter.com/igorasilveira">my Twitter profile</a>, come and say 'Hi! 👋'.</em></p>
<p>This article is part of an entire Next.js series of articles that I am putting together to help you become a Next.js pro and start building blazing fast React apps, either static, client-rendered, server-rendered or a mix of both (but we will get to that later).</p>
<p>💡 If you don’t want to miss out on any of the tutorials, signup for my newsletter by <a href="https://www.getrevue.co/profile/igorasilveira">clicking here</a> or head over to <a href="https://dailydev.io/">DailyDev.io</a> for more.</p>
<p>On this issue, we will be learning about how Next.js makes it incredibly easy to navigate between pages within our application using <em>prefetching</em> ensuring our app is fast and secure.</p>
<aside>
💡 You can find the source code for this project <a href="https://github.com/igorasilveira/blog-examples/tree/main/nextjs-basic-routing">here</a>.
</aside>
<p>So let’s get started!</p>
<h3>Pre-requisites</h3>
<ul>
<li>Node ≥ 12</li>
<li>React Basics</li>
</ul>
<h2>Creating a Next.js App</h2>
<p>To kick this off, we need our very own freshly-built Next.js which we can get by simply running this command in the directory you wish to store all of your awesome Next.js projects.</p>
<pre><code class="language-bash">npx create-next-app nextjs-basic-routing --use-npm --typescript
</code></pre>
<p><em>A breakdown of what we just did:</em></p>
<ul>
<li><code>npx</code> - is a command-line interface tool that makes it easy to execute npm packages without actually installing them on your own machine.</li>
<li><code>create-next-app</code> - our best friend, will scaffold a perfectly balanced Next.js app for you.</li>
<li><code>nextjs-basic-routing</code> - this is the name I decided to give my project, feel free to mix it up a bit.</li>
<li><code>--use-npm</code> - this flag specifies that we want to use NPM as our dependency manager.</li>
<li><code>--typescript</code> - this flag tells the scaffolding tool that we want to generate a TypeScript project and it initializes all required dependencies (this is more of a personal preference of mine - ❤️ TypeScript).</li>
</ul>
<h2>Running our App</h2>
<p>Our Next.js project has been created and all dependencies automatically installed. We can now run it and see our app come to life!</p>
<p>In the same terminal we used to scaffold our project, we now <code>cd</code> into our project folder ie. <code>cd nextjs-basic-routing</code> and we run the following command to start our project in <strong>development mode</strong>.</p>
<pre><code class="language-bash">npm run dev
</code></pre>
<p>After a couple of seconds, your Next.js app server is launched (hopefully with success) and you can now navigate to <code>http://localhost:3000</code> and reveal your Next.js app, similar to the one below.</p>
<p><img src="https://admitted-shamrock-c0f.notion.site/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2Fd173ed60-2ba7-489d-8438-7550084f648a%2FScreenshot_2022-02-17_at_07.48.19.png?table=block&#x26;id=53b58050-c151-46dc-9da1-7148d5817894&#x26;spaceId=a1132038-30f4-4c02-8dbb-44ea7cf0c715&#x26;width=2000&#x26;userId=&#x26;cache=v2" alt="Screenshot 2022-02-17 at 07.48.19.png"></p>
<p>We are now open for business! 🥳</p>
<h2>Next.js Routing</h2>
<p>Now that we have our application up and running, let’s start looking at how Next.js beautifully handles its pages and routing, starting by creating our very own new page.</p>
<h3>Pages</h3>
<p>In Next.js, every page is a React Component that is exported from a file that lives in the <code>/pages</code> directory at the root of your project. The name of the file dictates the route it will be associated with, including the folder(s), if any, that the React Component is living in. There is a special filename that is associated with the <strong>root</strong> of your app, and that is the <code>index.tsx</code> file already came included with our initial scaffolding.</p>
<ul>
<li><code>/pages/index.tsx</code> maps to the <code>/</code> route (our homepage)</li>
<li><code>/pages/dogs/a-doggo.tsx</code> maps to the <code>/dogs/a-doggo.tsx</code> route.</li>
</ul>
<h3>Creating a new Page</h3>
<p>So if we were to create that doggo page mapped to that specific route, I’d need to create a new folder within <code>/pages</code> and, inside that new folder, export a new React Component from a file named <code>a-doggo.tsx</code>. Your file tree would look something like this:</p>
<p><img src="https://admitted-shamrock-c0f.notion.site/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2Fde90c9d7-a2b4-47f1-ba74-57d2f642280f%2FScreenshot_2022-02-18_at_07.03.33.png?table=block&#x26;id=cb9d4ba9-6acb-4cb4-b1dd-75e77e56321f&#x26;spaceId=a1132038-30f4-4c02-8dbb-44ea7cf0c715&#x26;width=680&#x26;userId=&#x26;cache=v2" alt="Screenshot 2022-02-18 at 07.03.33.png"></p>
<p>(Don’t mind the <code>_app.tsx</code> file, for now, that is a special file)</p>
<p>The contents of the new file can be anything you wish, as long as it exports a default React Component that renders some JSX that Next.js can then render as HTML. For example, this is the code of my React Component.</p>
<pre><code class="language-tsx">import type { NextPage } from 'next'
import Head from 'next/head'
import Image from 'next/image'

const Doggo: NextPage = () => {
  return (
    &#x3C;div>
      &#x3C;Head>
        &#x3C;title>A Doggo&#x3C;/title>
      &#x3C;/Head>

      &#x3C;main>
        &#x3C;h1>
          This is a Doggo.
        &#x3C;/h1>

        &#x3C;Image alt="This is a doggo" src='https://loremflickr.com/520/520/dog' width={520} height={520}/>
      &#x3C;/main>
    &#x3C;/div>
  )
}

export default Doggo
</code></pre>
<p>I wanted to have a random image of a doggo, so I used <a href="https://loremflickr.com/">https://loremflickr.com</a>, a nice tool for randomly generated assets. In order for this to work with Next.js, we need to add this domain as an image provider in the <code>next.config.js</code> file as below. </p>
<p>(<strong>NOTE:</strong> this is optional and you can make your React Component show whatever you want and not use this image generator)</p>
<pre><code class="language-jsx">const nextConfig = {
  reactStrictMode: true,
  images: {
    domains: [
      "loremflickr.com"  // &#x3C;- added this
    ]
  }
}

module.exports = nextConfig
</code></pre>
<p>If we now run our server and navigate to <code>http://localhost:3000/dogs/a-doggo</code>, there will be a random image of a doggo for us to contemplate. 🐶</p>
<p><img src="https://admitted-shamrock-c0f.notion.site/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2Fc8f8c7c2-2c63-4919-91d9-c578097281ef%2FScreenshot_2022-02-18_at_07.29.49.png?table=block&#x26;id=d3940ba5-5c3b-4a47-81b2-f68ed839b28b&#x26;spaceId=a1132038-30f4-4c02-8dbb-44ea7cf0c715&#x26;width=2000&#x26;userId=&#x26;cache=v2" alt="Screenshot 2022-02-18 at 07.29.49.png"></p>
<h3>Navigating Static Routes</h3>
<p>Our application now has two pages, and to navigate between them we have been manually changing our URL in the address bar. Let’s change that!</p>
<p>Normally, we link between pages on our own or external website using the <code>&#x3C;a></code> HTML tag. But Next.js builds on top of that. You can use the <code>Link</code> Component to wrap the <code>&#x3C;a></code> tag, allowing you to do <strong>client-side navigation</strong> to a different page in the application.</p>
<p><strong>Client-side navigation</strong> means that the page transition happens using <em>JavaScript</em>, which is faster than the default browser navigation methods.</p>
<p>Another great benefit of using Next.js <code>Link</code> Component is that pages containing one or more <code>Link</code> Components will <strong>prefetch</strong> the code for the linked page in the background as soon as the <code>Link</code> becomes visible in the viewport. This allows for a faster initial page render as Next.js will only load the code for the page you requested and only load other linked pages when the <code>Link</code> Component is visible, and it does it in the background, not impacting the overall user experience and making the navigation extremely fast for a client-side application.</p>
<p>But how do we use it then? Well, it is pretty straightforward as using a normal <code>&#x3C;a></code> HTML tag would be. So let’s include a <code>Link</code> on our Homepage to go to our <em>doggo</em> page and another to get back home.</p>
<p>Replace your <code>/pages/index.tsx</code> code with the following:</p>
<pre><code class="language-jsx">import type { NextPage } from 'next'
import Head from 'next/head'
import Image from 'next/image'
import Link from 'next/link'
import styles from '../styles/Home.module.css'

const Home: NextPage = () => {
  return (
    &#x3C;div className={styles.container}>
      &#x3C;Head>
        &#x3C;title>Create Next App&#x3C;/title>
        &#x3C;meta name="description" content="Generated by create next app" />
        &#x3C;link rel="icon" href="/favicon.ico" />
      &#x3C;/Head>

      &#x3C;main className={styles.main}>
        &#x3C;h1 className={styles.title}>
          Welcome to &#x3C;a href="https://nextjs.org">Next.js!&#x3C;/a>
        &#x3C;/h1>

        &#x3C;p className={styles.description}>
          Let&#x26;apos;s check our &#x3C;Link href="dogs/a-doggo">doggo&#x3C;/Link>.
        &#x3C;/p>

      &#x3C;/main>

      &#x3C;footer className={styles.footer}>
        &#x3C;a
          href="https://vercel.com?utm_source=create-next-app&#x26;utm_medium=default-template&#x26;utm_campaign=create-next-app"
          target="_blank"
          rel="noopener noreferrer"
        >
          Powered by{' '}
          &#x3C;span className={styles.logo}>
            &#x3C;Image src="/vercel.svg" alt="Vercel Logo" width={72} height={16} />
          &#x3C;/span>
        &#x3C;/a>
      &#x3C;/footer>
    &#x3C;/div>
  )
}

export default Home
</code></pre>
<p>In your <code>/pages/a-doggo.tsx</code> replace your code with this one where we added a styled paragraph linking to our home page.</p>
<pre><code class="language-jsx">import type { NextPage } from 'next'
import Head from 'next/head'
import Image from 'next/image'
import Link from 'next/link'

const Doggo: NextPage = () => {
  return (
    &#x3C;div>
      &#x3C;Head>
        &#x3C;title>A Doggo&#x3C;/title>
      &#x3C;/Head>

      &#x3C;main>
        &#x3C;h1>
          This is a Doggo.
        &#x3C;/h1>

        &#x3C;Image alt="This is a doggo" src='https://loremflickr.com/520/520/dog' width={520} height={520}/>
        &#x3C;p style={{color: "#0070f3"}}>&#x3C;Link href="/">Back Home&#x3C;/Link>&#x3C;/p>
      &#x3C;/main>
    &#x3C;/div>
  )
}

export default Doggo
</code></pre>
<p>And now we can easily navigate through our application’s pages 😎</p>
<p><img src="https://admitted-shamrock-c0f.notion.site/image/https%3A%2F%2Fs3-us-west-2.amazonaws.com%2Fsecure.notion-static.com%2Fb9ca052a-8507-477c-b9f9-7bbb1dc74340%2FScreen_Recording_2022-02-19_at_08.34.36.gif?table=block&#x26;id=cc5f76c6-662b-4ca7-bbe2-47e533efcdb1&#x26;spaceId=a1132038-30f4-4c02-8dbb-44ea7cf0c715&#x26;userId=&#x26;cache=v2" alt="Screen Recording 2022-02-19 at 08.34.36.gif"></p>
<h2>Final Remarks</h2>
<p>Now that you have a working Next.js app up and running, don't stop there. As a good exercise, go ahead and create more pages for your application (<em>ie. About Us, Contacts</em>) and more doggos. If you run into any trouble feel free to reach out to me on <a href="https://twitter.com/igorasilveira">Twitter</a>, my DMs are always open.</p>
<p><strong>Next Steps:</strong> Keep an eye out for my following Next.js tutorials where we will go over <em>Dynamic Routes</em> and much more! If you don’t want to miss out on any of the tutorials, signup for my newsletter by <a href="https://www.getrevue.co/profile/igorasilveira">clicking here</a>.</p>


Learn about how Next.js makes it incredibly easy to navigate between pages within our application using prefetching ensuring our app is fast and secure.

A Comprehensive Guide to NextJS Routing

Authentication plays a major role in all systems around the globe in securing an application of any sort. In this article, I will show you how you can use Auth0 to secure your NextJS web application (including social login).

A Comprehensive Guide to NextJS Authentication with Auth0

*Hello, my name is Igor and if by chance, you enjoy what I write, you may also like what I have to say on [my Twitter profile]([https://www.twitter.com/igorasilveira](https://www.twitter.com/igorasilveira)), come and say 'Hi! 👋'.*

### Contents

- Clean Freak
- One-man Band vs. Enterprise
- The Tips

## Clean Freak

You may have been coding for a while now, but would you consider your code to be clean? When you are coding, do you take cleanliness into account (not relating to your surrounding btw, that's for another time)?

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." - Martin Fowler

It may be tempting to forget about doing a cleaning round once your code is up and running as expected (I know it is). It can happen often that we forget *how* we have written things and just call it a day. You may have also already taken into consideration some of the most common tips while developing your masterpiece, but chances are that if you go about the code with a pair of judgmental eyes, you'll find several *missing spots* (pun intended).

## One-man Band vs. Enterprise

When you are working on your side projects there is no implicit obligation of always committing the most impeccable code. You are there to have fun and learn a thing or two on your own time. You may have watched an awesome tutorial online and you couldn't wait to fire up your editor and create your own version of it.

**That is fine!** Coding on your own is mostly about having fun and loving what you do, but it may also be important that a couple of those online tutorials that you watch be about coding practices. Even on your own written projects, you will probably have a hard time figuring out what was done when you look back at it down the road.

Once you're in a work environment and the team is no longer comprised of you alone, things get a bit more serious. Several people are working on the same codebase, meaning that the code someone writes today may be in front of someone else tomorrow to add a new feature of some sort. This is when eyes will be directed at you and you'll most certainly be prompted to aid in understanding the *what* and the *why* of the code you have written.

Most clean code practices can be enforced at the time of code review before merging your changes into the project's main branch or even before it leaves the code editor, but, as I have experienced several times, many things can slip under the radar, only to be dug out later down the road.

## The Tips

With all the context already given, let's jump right into some important tips for writing your clean code.

### Tip \#1 - Write meaningful names

This first tip is often memed about around the internet, with my favorite being the *Narcos* meme. It is joked that a developer may spend more time on deciding how to name functions and variables, than actually coding a given feature. Although somewhat exaggerated, naming is an extremely important aspect of writing clean code. It helps to enable the code to be *self-documenting*, meaning that if at some point down the future you look back at old code, it should be like reading plain English.

![Meaningful variable and function names example](https://res.cloudinary.com/dydevwhyk/image/upload/q_auto/v1605452165/posts/meaningfulNames_t7eenc.png)

### Tip \#2 - Make the code readable

As with anything written, you will struggle to read it if it is all cluttered and doesn't follow any pre-existing formatting or agreed-upon structure. For example, you wouldn't be able to read code with ease if all of it was on the same line and had no spacing in between (this is an extreme example, but most parts of it are true).

Today, it is easy to fit your project with a *linter* that will automatically take care of that for you and check for inconsistencies. A linter operates on top of a set of rules that tell it how the code should be formatted and what syntax should be enforced. This is very common on larger teams where the code is verified before going to the main repository.

![Readable code example](https://res.cloudinary.com/dydevwhyk/image/upload/q_auto/v1605452165/posts/readableCode_pxmvhq.png)

### Tip \#3 - Classes and functions are concise and follow the Single Responsibility Principle (SRP)

I believe everyone would agree that a small and concise block of code would be easier to read than its counterpart. Apart from that, segmenting your code in each of its individual pieces would ease unit testing since you are testing small bits at a time, so you know exactly the source of the bug, and the debugging process is accelerated.

Of course, there will always be a handful of functions that you simply can't keep on a lower line count. However, that's when following SRP will reap its benefits by enabling the ability to pinpoint the source of a bug since it would be the only class or function with the responsibility to commit that change. Also, by following this principle, you would have an easier time naming the class or function because it only has one clear, simple job (instead of 4 or 5 mashed together).

### Tip \#4 - Remove duplicates

Duplicate code is the recipe for disaster. if at any point in the future you need to go back and edit it, you are extremely likely to not know that the same logic is replicated somewhere else, and thus, this is how many bugs are introduced into your system.

Once you are done coding your awesomely new feature, be sure to go back and re-read what you've coded and look for duplicates. These can be hiding in different forms of implementation, so keep your eyes wide open looking for these. Once spotted, extract that piece of duplicated code into a new method, mostly likely a helper. In the future, when something needs changing, you can refer simply to that extracted helper method, making the changes cheaper to conduct.

### Tip \#5 - Review other's code

It is easy to fall in love with your own code and, as they say, love is sometimes blind.

Reviewing other people's code, the same as reading someone's book, helps you open your mind to new realities. It is easier to be judgmental of other people's property instead of your own, so you can gain some insights from your own evaluation of their code. Keep in mind that can be both on the positive side and on the negative, the idea is that you will slowly but surely pick up a more refined sense of what is clean code and therefore, begin implementing it in your own work.

Of course that if you are working alone and have no other co-workers code to look at, you can always wander around some random GitHub accounts and see what they are up to. There is even a subreddit where people review each other's work, [check it out](https://www.reddit.com/r/reviewmycode/)!

Now get out there and start coding a bit cleaner and don't worry that with time everything gets easier, just keep going strong!

<p><em>Hello, my name is Igor and if by chance, you enjoy what I write, you may also like what I have to say on <a href="%5Bhttps://www.twitter.com/igorasilveira%5D(https://www.twitter.com/igorasilveira)">my Twitter profile</a>, come and say 'Hi! 👋'.</em></p>
<h3>Contents</h3>
<ul>
<li>Clean Freak</li>
<li>One-man Band vs. Enterprise</li>
<li>The Tips</li>
</ul>
<h2>Clean Freak</h2>
<p>You may have been coding for a while now, but would you consider your code to be clean? When you are coding, do you take cleanliness into account (not relating to your surrounding btw, that's for another time)?</p>
<p>"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." - Martin Fowler</p>
<p>It may be tempting to forget about doing a cleaning round once your code is up and running as expected (I know it is). It can happen often that we forget <em>how</em> we have written things and just call it a day. You may have also already taken into consideration some of the most common tips while developing your masterpiece, but chances are that if you go about the code with a pair of judgmental eyes, you'll find several <em>missing spots</em> (pun intended).</p>
<h2>One-man Band vs. Enterprise</h2>
<p>When you are working on your side projects there is no implicit obligation of always committing the most impeccable code. You are there to have fun and learn a thing or two on your own time. You may have watched an awesome tutorial online and you couldn't wait to fire up your editor and create your own version of it.</p>
<p><strong>That is fine!</strong> Coding on your own is mostly about having fun and loving what you do, but it may also be important that a couple of those online tutorials that you watch be about coding practices. Even on your own written projects, you will probably have a hard time figuring out what was done when you look back at it down the road.</p>
<p>Once you're in a work environment and the team is no longer comprised of you alone, things get a bit more serious. Several people are working on the same codebase, meaning that the code someone writes today may be in front of someone else tomorrow to add a new feature of some sort. This is when eyes will be directed at you and you'll most certainly be prompted to aid in understanding the <em>what</em> and the <em>why</em> of the code you have written.</p>
<p>Most clean code practices can be enforced at the time of code review before merging your changes into the project's main branch or even before it leaves the code editor, but, as I have experienced several times, many things can slip under the radar, only to be dug out later down the road.</p>
<h2>The Tips</h2>
<p>With all the context already given, let's jump right into some important tips for writing your clean code.</p>
<h3>Tip #1 - Write meaningful names</h3>
<p>This first tip is often memed about around the internet, with my favorite being the <em>Narcos</em> meme. It is joked that a developer may spend more time on deciding how to name functions and variables, than actually coding a given feature. Although somewhat exaggerated, naming is an extremely important aspect of writing clean code. It helps to enable the code to be <em>self-documenting</em>, meaning that if at some point down the future you look back at old code, it should be like reading plain English.</p>
<p><img src="https://res.cloudinary.com/dydevwhyk/image/upload/q_auto/v1605452165/posts/meaningfulNames_t7eenc.png" alt="Meaningful variable and function names example"></p>
<h3>Tip #2 - Make the code readable</h3>
<p>As with anything written, you will struggle to read it if it is all cluttered and doesn't follow any pre-existing formatting or agreed-upon structure. For example, you wouldn't be able to read code with ease if all of it was on the same line and had no spacing in between (this is an extreme example, but most parts of it are true).</p>
<p>Today, it is easy to fit your project with a <em>linter</em> that will automatically take care of that for you and check for inconsistencies. A linter operates on top of a set of rules that tell it how the code should be formatted and what syntax should be enforced. This is very common on larger teams where the code is verified before going to the main repository.</p>
<p><img src="https://res.cloudinary.com/dydevwhyk/image/upload/q_auto/v1605452165/posts/readableCode_pxmvhq.png" alt="Readable code example"></p>
<h3>Tip #3 - Classes and functions are concise and follow the Single Responsibility Principle (SRP)</h3>
<p>I believe everyone would agree that a small and concise block of code would be easier to read than its counterpart. Apart from that, segmenting your code in each of its individual pieces would ease unit testing since you are testing small bits at a time, so you know exactly the source of the bug, and the debugging process is accelerated.</p>
<p>Of course, there will always be a handful of functions that you simply can't keep on a lower line count. However, that's when following SRP will reap its benefits by enabling the ability to pinpoint the source of a bug since it would be the only class or function with the responsibility to commit that change. Also, by following this principle, you would have an easier time naming the class or function because it only has one clear, simple job (instead of 4 or 5 mashed together).</p>
<h3>Tip #4 - Remove duplicates</h3>
<p>Duplicate code is the recipe for disaster. if at any point in the future you need to go back and edit it, you are extremely likely to not know that the same logic is replicated somewhere else, and thus, this is how many bugs are introduced into your system.</p>
<p>Once you are done coding your awesomely new feature, be sure to go back and re-read what you've coded and look for duplicates. These can be hiding in different forms of implementation, so keep your eyes wide open looking for these. Once spotted, extract that piece of duplicated code into a new method, mostly likely a helper. In the future, when something needs changing, you can refer simply to that extracted helper method, making the changes cheaper to conduct.</p>
<h3>Tip #5 - Review other's code</h3>
<p>It is easy to fall in love with your own code and, as they say, love is sometimes blind.</p>
<p>Reviewing other people's code, the same as reading someone's book, helps you open your mind to new realities. It is easier to be judgmental of other people's property instead of your own, so you can gain some insights from your own evaluation of their code. Keep in mind that can be both on the positive side and on the negative, the idea is that you will slowly but surely pick up a more refined sense of what is clean code and therefore, begin implementing it in your own work.</p>
<p>Of course that if you are working alone and have no other co-workers code to look at, you can always wander around some random GitHub accounts and see what they are up to. There is even a subreddit where people review each other's work, <a href="https://www.reddit.com/r/reviewmycode/">check it out</a>!</p>
<p>Now get out there and start coding a bit cleaner and don't worry that with time everything gets easier, just keep going strong!</p>


You may have been coding for a while now, but would you consider your code to be clean? When you are coding, do you take cleanliness into account (not relating to your surrounding btw, that's for another time)?

5 Tips That Will Enable You to Write Cleaner Code

Tips

Hello, my name is Igor and if by chance, you enjoy what I write, you may also like what I have to say on [my Twitter profile](https://www.twitter.com/igorasilveira).

### Contents

- The Idea 💡
- The Flawed Creator 🧠
- Feeling Lost 😩
- The Indie Developer Journey 💻
- The Masterplan 🗒
- Takeaways ✅

## The Idea 💡

Let me paint you a picture:

You are in the middle of taking the most relaxing shower you had taken in a long time. Amidst massaging your head to evenly apply the shampoo, all your neurons fired at once and you were hit with the most amazing idea ever! You rush to finish the cleansing, dry yourself, and start working on it ASAP.

"This is going to be the best product ever!" - you say.

## The Flawed Creator 🧠

Our brain is an incredible piece of organic machinery and it is creative by default, ideas come to individuals naturally, from the most simple to the most complex, and some have a bit too many probably.

What our brain is not so good at, is storing those ideas efficiently and for easy access. How many times haven't I had an incredible idea to forget it afterward nothing short of 5 minutes. Many productivity masters realize this incapability of our center of operations and recommend to always have on hand some note-taking apparatus - digital or not.

I couldn't agree more (remember the 5-minute memory loss?).

## Feeling Lost 😩

It isn't long before you start realizing how much there needs to be done that you don't even know how to quantify it yet. What was once a sweet little nifty idea is now starting to get overly complicated (at least inside your head) and you are starting to feel overwhelmed. If all goes wrong, within a couple of weeks, you give up on the project because you don't know where to turn next.

This process may have already happened to you once or on repeat. You have by now either learned how to control this inner affluence of information, or you are still lost in your thoughts. For the latter case, I hope this will help.

## The Indie Developer Journey 💻

I believe many of us would consider ourselves to be some kind of an indie developer. After all, we do have our own side projects that we mainly work on alone. All projects are different, but they all follow the same journey from idea to conception. A list of steps can be roughly summarized by:

1. Features - what does it do or allow others to?
2. Design - how does it look? (good probably)
3. Architecture - how does it function on the inside and out?

We certainly are not strong in all of the above steps, but we can still craft something on each level and come out with a working product.

> The biggest mistake that the brave indie developer can do is to be all over the place.

The eagerness to be all hands on coding the new idea right out of the shower is understandable, you are extremely excited to get it going, but that approach normally leads to a black-hole of a lifetime of discarded projects.

Remember, our brain can't easily store all those great ideas and manage them efficiently. It gets them all mixed up and tangled, leaving you with nothing but a bowl of idea noodles when you try to process them all at once.

## The Masterplan 🗒

The solution to being able to sail that ship home (I mean the new project to its final host) successfully is to plan ahead. Simple as that. 

Splitting your tasks helps to keep you from feeling overwhelmed.

If you spend a couple of side-project working days with the sole goal of organizing the development journey ahead, you will be able to lift 2 metric tons out of your shoulders.

The plan should still follow the aforementioned order. Start with defining your desired implemented features. The design phase follows next since you now know exactly WHAT you want to build. The architectural part can be last now that you know what information is required to store and access, and at what points in time.

The best way I found to organize my projects' requirements, is to use a drag-and-drop board that could either contemplate all the 3 stages at once or even have a board for each (probably depends on the overall application size). The most known tool for this is probably [Trello](https://trello.com/), but my best heartfelt recommendation goes to [Notion](https://www.notion.so/). At first glance, Notion might seem daunting to use, but once you get around to know it you will realize just how powerful it can be.

![Notion GIF Example](https://res.cloudinary.com/dydevwhyk/image/upload/q_auto/v1599300538/posts/Screenshot_2020-09-05_at_11.06.12_rylkay.png)

Don't forget that a nice pen and paper will also suffice!

## Takeaways ✅

- Our brain is great at coming up with ideas but terrible at storing them for easy access later.
- The biggest mistake that the brave indie developer can do is to be all over the place.
- Splitting your tasks helps to keep you from feeling overwhelmed.
- Using some kind of drag-and-drop board to organize your tasks.

As always, if you enjoyed reading this and want to reach out to me, let's connect! [@igorasilveira](https://www.twitter.com/igorasilveira).

<p>Hello, my name is Igor and if by chance, you enjoy what I write, you may also like what I have to say on <a href="https://www.twitter.com/igorasilveira">my Twitter profile</a>.</p>
<h3>Contents</h3>
<ul>
<li>The Idea 💡</li>
<li>The Flawed Creator 🧠</li>
<li>Feeling Lost 😩</li>
<li>The Indie Developer Journey 💻</li>
<li>The Masterplan 🗒</li>
<li>Takeaways ✅</li>
</ul>
<h2>The Idea 💡</h2>
<p>Let me paint you a picture:</p>
<p>You are in the middle of taking the most relaxing shower you had taken in a long time. Amidst massaging your head to evenly apply the shampoo, all your neurons fired at once and you were hit with the most amazing idea ever! You rush to finish the cleansing, dry yourself, and start working on it ASAP.</p>
<p>"This is going to be the best product ever!" - you say.</p>
<h2>The Flawed Creator 🧠</h2>
<p>Our brain is an incredible piece of organic machinery and it is creative by default, ideas come to individuals naturally, from the most simple to the most complex, and some have a bit too many probably.</p>
<p>What our brain is not so good at, is storing those ideas efficiently and for easy access. How many times haven't I had an incredible idea to forget it afterward nothing short of 5 minutes. Many productivity masters realize this incapability of our center of operations and recommend to always have on hand some note-taking apparatus - digital or not.</p>
<p>I couldn't agree more (remember the 5-minute memory loss?).</p>
<h2>Feeling Lost 😩</h2>
<p>It isn't long before you start realizing how much there needs to be done that you don't even know how to quantify it yet. What was once a sweet little nifty idea is now starting to get overly complicated (at least inside your head) and you are starting to feel overwhelmed. If all goes wrong, within a couple of weeks, you give up on the project because you don't know where to turn next.</p>
<p>This process may have already happened to you once or on repeat. You have by now either learned how to control this inner affluence of information, or you are still lost in your thoughts. For the latter case, I hope this will help.</p>
<h2>The Indie Developer Journey 💻</h2>
<p>I believe many of us would consider ourselves to be some kind of an indie developer. After all, we do have our own side projects that we mainly work on alone. All projects are different, but they all follow the same journey from idea to conception. A list of steps can be roughly summarized by:</p>
<ol>
<li>Features - what does it do or allow others to?</li>
<li>Design - how does it look? (good probably)</li>
<li>Architecture - how does it function on the inside and out?</li>
</ol>
<p>We certainly are not strong in all of the above steps, but we can still craft something on each level and come out with a working product.</p>
<blockquote>
<p>The biggest mistake that the brave indie developer can do is to be all over the place.</p>
</blockquote>
<p>The eagerness to be all hands on coding the new idea right out of the shower is understandable, you are extremely excited to get it going, but that approach normally leads to a black-hole of a lifetime of discarded projects.</p>
<p>Remember, our brain can't easily store all those great ideas and manage them efficiently. It gets them all mixed up and tangled, leaving you with nothing but a bowl of idea noodles when you try to process them all at once.</p>
<h2>The Masterplan 🗒</h2>
<p>The solution to being able to sail that ship home (I mean the new project to its final host) successfully is to plan ahead. Simple as that. </p>
<p>Splitting your tasks helps to keep you from feeling overwhelmed.</p>
<p>If you spend a couple of side-project working days with the sole goal of organizing the development journey ahead, you will be able to lift 2 metric tons out of your shoulders.</p>
<p>The plan should still follow the aforementioned order. Start with defining your desired implemented features. The design phase follows next since you now know exactly WHAT you want to build. The architectural part can be last now that you know what information is required to store and access, and at what points in time.</p>
<p>The best way I found to organize my projects' requirements, is to use a drag-and-drop board that could either contemplate all the 3 stages at once or even have a board for each (probably depends on the overall application size). The most known tool for this is probably <a href="https://trello.com/">Trello</a>, but my best heartfelt recommendation goes to <a href="https://www.notion.so/">Notion</a>. At first glance, Notion might seem daunting to use, but once you get around to know it you will realize just how powerful it can be.</p>
<p><img src="https://res.cloudinary.com/dydevwhyk/image/upload/q_auto/v1599300538/posts/Screenshot_2020-09-05_at_11.06.12_rylkay.png" alt="Notion GIF Example"></p>
<p>Don't forget that a nice pen and paper will also suffice!</p>
<h2>Takeaways ✅</h2>
<ul>
<li>Our brain is great at coming up with ideas but terrible at storing them for easy access later.</li>
<li>The biggest mistake that the brave indie developer can do is to be all over the place.</li>
<li>Splitting your tasks helps to keep you from feeling overwhelmed.</li>
<li>Using some kind of drag-and-drop board to organize your tasks.</li>
</ul>
<p>As always, if you enjoyed reading this and want to reach out to me, let's connect! <a href="https://www.twitter.com/igorasilveira">@igorasilveira</a>.</p>


Our brain is great at coming up with ideas but terrible at storing them for easy access later. The biggest mistake that the brave indie developer can do is to be all over the place.