Entriamo nel vivo di NextJS con alcune delle sue feature più interessanti.

Completiamo e ordiniamo il nostro blog


NextJS e React sono dei tool molto usati nel mondo dello sviluppo web moderno. Chiunque voglia diventare
uno sviluppatore web può puntare su questi progetti per iniziare ad imparare e sviluppare i propri progetti.

Questo corso, raccolto qui come un lungo e completo tutorial, è un mio piccolo esperimento per iniziare
la scrittura di un libro completo ed introduttivo rivolto a persone che vogliono avvicinarsi in modo completo
al mondo dello sviluppo web.

Il corso sarà composto di una serie di capitoli con materiale misto tra video tutorial e materiale scritto. Inoltre,
la parte scritta di questo corso sarà resa gratuitamente disponibile all'interno del mio blog per
chiunque voglia visualizzarlo.

Il corso è in fase di scrittura, e chiedo a chi lo seguirà di darmi il più possibile feedback e suggerimenti per renderlo
più completo e più utile ai più. A breve, inoltre, renderò possibile agli interessati ad iscriversi al corso
per accedere a tutto il materiale che sto producendo ad un prezzo vantaggioso! Quindi rimanete sintonizzati
su questo blog per saperne di più!

## Introduzione

Benvenuti nel mio progetto **NextJS Mega Tutorial**!
In questa serie di articoli voglio condividere la mia esperienza nello sviluppo reale di applicazioni con NextJS e Javascript.
Insieme vederemo come sviluppare e deployare applicazioni complete usando NextJS, React e l'ecosistema Javascript.

A differenza di molte altre risorse e tutorial che si trovano in rete, **NextJS Mega Tutorial** vi porterà all'interno di
un viaggio nello sviluppo software completo. Insieme non vedremo esempi isolati, ma vi mostrerò qual è il processo completo
per sviluppare applicativi web completi e non banali.
Quando raggiungeremo la fine del viaggio, avremmo sviluppato insime un progetto completo di cui conoscerete ogni linea di codice.
Cosa più importante, capirete nel dettaglio tutte le tecnologie, i concetti e le tecniche che utilizzano gli sviluppatori
professionali per creare progetti complessi, e sarete in grado di applicare questi concetti ai vostri progetti personali e lavoriativi.

## Prerequisiti

Per ottenere il massimo da questa serie di tutorial devi avere una minima esperienza nello
sviluppare applicativi con Javascript. Se hai sviluppato siti internet (o parti di questi)
usando _Vanilla Javascript_ o librerie come _JQuery_ dovrebbe andare bene.

Una minima conoscenza di HTML e CSS è anchenecessaria. Come nel caso di Javascript, una
esperienza base con queste tencologie è sufficiente. Io assumo che tu sappia come creare
una semplice pagina HTML usando elementi come `<p>`, `<h1>`, `<img>` e `<div>`, e come usare
CSS per applicare stili a questi elementi.

Una conoscenza base della command line del sistema operativo è anche utile.
Passeremo la maggior parte del tempo ad implementare codice nell'editor di testo, ma alcune
operazioni devono necessariamente essere eseguite dalla commmand line del sistema operativo.

Se usi Windows, consiglio di usare [il sottosistema Windows per Linux](https://docs.microsoft.com/it-it/windows/wsl/about),
che mette a disposizione una bash compatibile con i comandi UNIX e bash, node.js e gli altri comandi che utilizzeremo. Usare
windows con PowerShell è possibile ma richiederà alcune modifiche alla command line rispetto a quelle che userò io in questa serie
di tutorial. Su Mac o Linux potete usare il terminale integrato nel sistema operativo.

Come editor di testo per scrivere consiglio di usare [Visual Studio Code](https://code.visualstudio.com/), l'editor di testo
di riferimento per lo sviluppo software (specialmente in ambito web), che potete scaricare gratuitamente dal sito su tutte le piattaforme.

Per testare l'applicazione che svilupperemo, potete usare il vostro browser preferito.
Il mio cosiglio è di usare Chrome o Firefox, che sono i browser più usati per lo sviluppo web, in quanto sono
compatibili con il plugin [React Developer Tool](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi),
molto utile per fare debug delle applicazioni React (la libreria grafica alla base di NextJS).

Questo corso sarà a disposizione in una combinazione di materiale in forma scritta e video. Il corso è a pagamento ma la parte
scritta del tutorial è anche disponibile gratuitamente su questo blog.

Pronto per iniziare? Il primo capitolo ti aspetta!


NextJS e React sono dei tool molto usati nel mondo dello sviluppo web moderno. Chiunque voglia diventare uno sviluppatore web può puntare su questi progetti per iniziare ad imparare e sviluppare i propri progetti.

NextJS Mega Tutorial

JavaScript è in continua evoluzione, facciamo una breve carrellata delle feature di JavaScript moderno che andremo ad utilizzare in questo corso!

Javascript Moderno

Iniziamo a usare React e NextJS creando un semplice progetto

Primi passi con NextJS

Come funzionano i React Components e come possiamo usarli per costrire la nostra applicazione

Introduzione ai React Components

Lo stile dei componenti è un'attività essenziale ma molto complessa. In questa guida non voglio insegnarvi ad usare lo stile, ma presentarvi alcune tecniche molto utili per iniziare ad aggiungere stile ai nostri component.

Stilizziamo i componenti


Negli ultimi due capitoli abbiamo principalmente lavorato con React e visto come creare e gestire
componenti, utilizzando le props, settando gli stili ecc.

Quello imparato nel capito precedenti non è nulla di specifico su NextJS, e può essere tranquillamente
applicato (con alcune modifiche) a qualsiasi progetto React su cui vogliamo lavorare. In questo capitolo, invece,
iniziamo ad addentrarci dentro alcune delle feature più importanti di NextJS che lo hanno
reso uno dei (meta)framework più famosi e versatili nel panorama dello sviluppo software moderno in React.

Il modello di **data fetching** di NextJS permette di renderizzare le pagine e i contenuti in
diversi modi in base alle esigenze del nostro sito, o della specifica pagina che vogliamo renderizzare.
In particolare NextJS permette di renderizzare le pagine nei seguenti modi:

- **Static Site Generation (SSG)** dove i contenuti per renderizzare una pagina
  vengono prelevati in fase di compilazione del sito internet e poi messi a disposizione agli utenti tramite cache.
  Gli utenti si trovano a servire una pagina super veloce, perchè questa è già stata costruita dal server. Inoltre
  non abbiamo necessità di consumerare risorse lato server per servire questa pagina: la pagina è già pronta e
  il server deve solo servire il file statico all'utente. Questo approccio funziona molto bene in caso di dati
  che non variano velocemente (come blog post), ma non è adatto in caso di dati che variano velomenete.
- **Server Site Rendering (SSR)** dove i contenuti vengono richiesti nel momento in cui l'utente fa
  la richiesta al server e presentanti all'utente immediatamente. Questo è il modo in cui i siti internet dinamici (come ad esempio quelli
  basati su wordpress) storicamente funzionano. Questo approccio richiede risorse computazionali per gestire la pagina, in quanto
  il server deve fare la query di dati a sorgenti terze (un db, altre api, eccetera) e poi renderizzare la pagina prima di servirla.
- **Client-side Rendering (CSR)**, dove riprendiamo il vantaggio di avere applicazioni completamente gestite dal browser. In questo caso il server
  si occupa di servire una pagina HTML con del codice JavaScript. La pagina, una volta eseguita sul browser, si occuperò di
  fare query di altri dati e di aggiornare il contenuto che viene mostrato all'utente. Questo approccio è molto popolare per appliacazioni
  che non richiedono l'indicizzazione SEO (in quanto i servizi che indicizzano le pagina solitamente non eseguino il codice JavaScript) e
  che richiede forte interazione con i dati da parte dell'utente. Da notare che questa terza tecnica può essere usata insieme ad una delle altre
  due in acluni casi, ad esempio una pagina renderizzata staticamente con alcuni dati che vengono aggiornati dal browser.
- **Incremental Static Regeneration (ISR)**, è un approccio misto tra **SSG** e **SSR**, in qesto caso la pagina viene prerenderizzata
  ma il server si occupa periodicamente di fare un refetch dei dati e di aggiornare il contenuto della pagina cachata se i dati cambiano.
  In questo caso abbiamo i vantiaggi di una pagina statica (all'utente arriva senpre la cache) con la possibilità di decidere quanto spesso
  controllarne l'aggiornamento.

<InfoBox>
  Durante lo sviluppo, le pagine **SSG** e **SSR** si comportano di fatto nello
  stesso modo, per autare lo sviluppo.

La differenza tra le due modalità di rendering viene vista in fase di rilascio del sito in prodizione.

</InfoBox>

In questo capitolo ci concentreremo sull'uso di **SSG** (e della sua evoluzione **ISR**). Questa soluzione ci darà la possibilità,
nei due capitoli successivi, di iniziare a costuire un semplice blog e metterlo a disposizione di tutti.

Appronfondiremo poi in seguito le soluzione **SSR** e **CSR** che richiedono una conoscenza più complessa delle tecnologie in gioco, ma
grazie ai quali possiamo realizzare siti molto più complessi.

### Static Site Generation (SSG) con `getStaticProps`

Le pagine che abbiamo costruito fino ad ora sono di fatto pagina statiche, andiamo ad esempio a prendere la pagina principale, che
troviamo nel file `pages/index.tsx`:

```tsx
import { Footer } from "../components/footer";
import { Nav } from "../components/nav";

const Home = () => {
  return (
    <div className="">
      <Nav />
      <h1> Home </h1>
      <Footer />
    </div>
  );
};

export default Home;
```

Ci accorgiamo subito che questa pagina non contiene alcun dato esterno da mostrare, non cambia quindi per nessun motivo se non
cambiamo il codice che la compone.

In questo caso, la pagina viene considerata da NextJS come una pagina statica (o meglio un caso particolare di una pagina statica
che non contiene nemmeno dati), e in fase di compilazione del sito, verrà renderizzata, cachata e servita all'utente così come è.

Esiste però un modo per controllare la renderizzazione di questa pagina in fase di build e passargli dei dati che arrivano da fonti
esterne. Questo viene fatto esportando una funzione speciale dalla pagina chiamata `getStaticProps`.

```tsx
export const getStaticProps = async () => {
  return {
    props: {},
  };
};
```

Questa funzione viene eseguita (lato server) nel momento del build del sito, e l'oggetto `props` che viene tornato
da questa funzione viene passato come proprietà al componente della pagina che esportiamo. Con questa semplice soluzione, di fatto,
possiamo controllare in modo molto specifico qualisasi dato che passiamo al componente che renderizza la pagina. L'unico vincolo è
che l'oggetto che mettiamo all'interno di props deve essere JSON serializzabile (cioè non possiamo passare classi o funzioni, ma solo dati
che possiamo mettere all'interno di un oggetto JSON), ad esemio, non possiamo passare una oggetti `Date` o un componente React.

Possiamo quindi usare queste informazioni per renderizzare la pagina. Supponiamo ad esempio di voler inserire da qualche parte
il momento in cui la pagina viene renderizzata, possiamo fare così:

```tsx
export const getStaticProps = async () => {
  const renderedTime = new Date();
  return {
    props: {
      renderedTime: renderedTime.toISOString(),
    },
  };
};
```

e accedere a questa informazione lato frontend:

```tsx
interface HomeProps {
  renderedTime: string;
}

const Home = ({ renderedTime }: HomeProps) => {
  return (
    <div className="">
      <Nav />
      <h1> Home </h1>
      <p>Renderizzato in data: {renderedTime}</p>
      <Footer />
    </div>
  );
};
```

Che renderizzerà questa pagina:

![Static Site Generation](./ssg1.png)

### Buildiamo il sito

Come detto prima, vi accorgerete che, facendo un refresh della pagina, il valore stampato della data cambierà. Questo perchè siamo
in modalità development e per semplicare lo sviluppo la funzione `staticSiteProps` viene eseguita continuamente. Possiamo però
provare a compilare il sito e servirlo in fase di prod.

Compiliamo prima di tutto il sito con il comando

```bash
$ npx run build
> my-first-site@0.1.0 build
> next build

info  - Checking validity of types
info  - Creating an optimized production build
info  - Compiled successfully
info  - Collecting page data
info  - Generating static pages (6/6)
info  - Finalizing page optimization

Page                                       Size     First Load JS
┌ ● /                                      2.68 kB        94.9 kB
├   /_app                                  0 B            75.1 kB
├ ○ /404                                   193 B          75.3 kB
├ ○ /about                                 2.63 kB        94.8 kB
├ λ /api/hello                             0 B            75.1 kB
├ ○ /blog                                  2.63 kB        94.8 kB
└ ○ /experiments                           3.1 kB         95.3 kB
+ First Load JS shared by all              75.1 kB
  ├ chunks/framework-a87821de553db91d.js   45 kB
  ├ chunks/main-fc7d2f0e2098927e.js        28.7 kB
  ├ chunks/pages/_app-43ac001d99fedbd3.js  493 B
  ├ chunks/webpack-fd1bc4a65a80e5c8.js     968 B
  └ css/45410aee82e1c763.css               1.8 kB

λ  (Server)  server-side renders at runtime (uses getInitialProps or getServerSideProps)
○  (Static)  automatically rendered as static HTML (uses no initial props)
●  (SSG)     automatically generated as static HTML + JSON (uses getStaticProps)
```

Notante intanto che NextJS ci segnala che la pagina `/` è di tipo **SSG** con il pallino ●. Le altre pagina che abbiamo
creato invece le considera **Static** (○), questo perchè contengono solo codice JavaScript e non dati.

Possiamo ora servire il server in modalità prod, e vedere come cambia il comportamento della pagina:

```bash
$ npm run start

> my-first-site@0.1.0 start
> next start

ready - started server on 0.0.0.0:3000, url: http://localhost:3000
```

A questo punto, se provate a refreshare la pagina varie volte, vedrete che il valore della data non cambia più, e risulterà essere quello
calcolato in fase di build durante il comando `npm run build`.

### Incremental Site Regeneration (ISR)

La tecnologia **ISR** è un'evoluzione della **SSG** in NextJS che ci permette di controllare il momento in cui una pagina viene
rirenderizzata. Il suo utilizzo è semplicissimo, in quanto basta che `getStaticProps` ritorni un oggetto contenente la proprietà `revalidate`.
`revalidate` è un numero rappresentate il periodo (in secondi) in cui la pagina deve rivenire aggiorata.

In fase di produzione, la funzione `getStaticProps` verrà eseguita alla scadenza di ogni intervallo di tempo prefissato e la cache della
pagina verà rirenderizzata.

Vediamo un esempi:

```tsx
export const getStaticProps = async () => {
  const renderedTime = new Date();
  return {
    props: {
      renderedTime: renderedTime.toISOString(),
    },
    revalidate: 10,
  };
};
```

In questo modo, se provate nuovamente a compilare e servire la pagina con `npm run start` vi accorgerete che il valore stampato
cambia all'incirca ogni 10 secondi.

<InfoBox>
`revalidate` è una feature molto potente di NextJS. Il valore che impostiamo all'interno di questo oggetto deve essere
settato in base a quanto frequente i nostri dati cambiano. Ad esempio in un blog post, ci aspettiamo che il contenuto non cambi 
molto spesso, perciò possiamo settare il valore a qualche ora (nel caso volessimo correggere eventuali errori) o non metterlo proprio.

In caso di una pagina che mostra una lista di blog post, possiamo settarlo a qualche minuto, in modo che la pagina si refreshi
abbastanza spesso da mostrare gli ultimi contenuti pubblicati.

</InfoBox>

### Inferenza dei tipi

Avete notato che abbiamo dovuto definire il tipo `Props` che passiamo alla pagina nonostante in teoria lo passimo già in quanto valore di ritorno
della funzione `getStaticProps`? Questa cosa, che non ci è costata tanto codice, in generale può essere scomoda da fare quando ritorniamo dalla
nostra pagina tantissimi oggetti. Fortunatamente, NextJS ci mette a disposizione una **type function** in typescript che ci permette dice
inferire il tipo di props dalla funzione. Questa funzione si chiama `InferGetStaticPropsType` e è disponibile nella libreria `@types/next`

```tsx
import { InferGetStaticPropsType } from "next";
// ...

type HomeProps = InferGetStaticPropsType<typeof getStaticProps>;

const Home = ({ renderedTime }: HomeProps) => {
  return (
    <div className="">
      <Nav />
      <h1> Home </h1>
      <p>Renderizzato in data: {renderedTime}</p>
      <Footer />
    </div>
  );
};
```

Questa funzione utilizziamo ci permette di mantenere i tipi corretti anche senza doverli definire manualmente.
Se provate a ritornare nuove proprietà dell'oggetto `props` vi accorgerete che queste vengono automaticamente
riconosciute dal tipo `HomeProps`.

## Cosa abbiamo imparato?

In questo capitolo abbiamo iniziato a scalfire le enormi potenzialità di NextJS nel creare siti complessi, vedendo come usare
la funzione `getStaticProps` per renderizzare la pagina in modalità **SSG**.

In particolare abbiamo visto:

- I diversi modelli di rendering e fetching dei dati in NextJS
- Come funziona `getStaticProps` per renderizzare una pagina in SSG
- Come usare `revalidate` per controllare la rigenerazione della pagina (ISR)
- Come sfruttare `InferGetStaticPropsType` per non dover definire il tipo `Props` a mano

Adesso abbiamo finalmente gli strumenti per iniziare a costruire un semplice blog con NextJS. Nel prossimi capitoli
vedremo quindi come costruire il nostro blog usando NextJS e Markdown (o una sua evoluzione chiamata MDX), la stessa
tecnologia con cui gestisco il mio blog e con cui sto scrivendo questo libro.

Nel frattempo, potete trovare il (poco) codice scritto in questo capito su [GitHub](https://github.com/ludusrusso/next-js-megatutorial/tree/c4)


Static Site Generation in NextJS

Abbiamo finalmente tutti i componenti per iniziare a costruire il nostro blog

Iniziamo a costruire il nostro blog con Content Layer


Nel capitolo precedente abbiamo visto come gestire i nostri blog post con ContentLayer e abbiamo iniziato a creare
le anteprima dei post all'interno della homepage del nostro blog.

Quello che però ancora non abbiamo fatto è creare delle pagine apposite per ogni blog in modo che l'utente possa
visualizzarli e leggere il proprio contenuto. Questa funzionalità, che implementiamo in questo capitolo, ci permetterà
di scoprire alcune feature interessanti di NextJS e ContentLayer, che sono:

1. NextJS dynamic routes, che ci permettono di creare delle pagine con path (cioè url) parametrizzabile.
2. Content Layer computed fields, che ci permette di creare delle proprietà calcolate in automatico dei nostri contenuti.

#### Quindi, che cosa faremo nel pratico?

Per prima cosa dobbiamo creare una path alla quale ogniuno dei nostri post dovrò rispondere. Ci sono vari modi per farlo, quella che ho
scelto io è nella seguente forma: `/blog/<yyyy>-<mm>-<dd>-<slug>`, che contiene la data di pubblicazione e il titolo del post sotto forma di slug.

Per slug si intende una stringa che contiene solo caratteri alfanumerici, trattini e trattini bassi, e che è quindi url friendly.

Per computare il path andremo ad usare le computed fields di ContentLayer, che ci permettono di precalcolare dei valori a partire dalle props
che passiamo al contenuto e di inserire come props nel contenuto stesso.

La seconda cosa che dobbiamo fare, invece, è quella di creare una pigina specifica in grado di renderizzare il contenuto del post. Questa pagina
sarà un componente unico che però renderizzerà informazioni diverse in base al post che si sta visualizzando.

## Calcolare il path con le computed fields di ContentLayer

Per calcolare il path di un post dobbiamo usare le computed fields di ContentLayer. Per definire un compute field
dobbbiamo definire la property `computeFields` dentro l'oggetto `BlogPost` nel file `contentlayer.config.ts`.
Questa property funziona come `fields`, con la differenza che dobbiamo passare ad ogni oggetto che definiamo qui
dentro una funzione `resolve` in cui mettiamo la logica per calcolare il valore della field che vogliamo.

Questa funzione resolve prende l'oggetto originale con le sue proprietà e deve ritornare il valore calcolato per
la nuova proprietà. Vediamo quindi come creare il field path:

```ts
export const BlogPost = defineDocumentType(() => ({
  name: "BlogPost",
  filePathPattern: `blog/**/*.(md|mdx)`,
  contentType: "mdx",
  fields: {
    // ...
  },
  computedFields: {
    path: {
      type: "string",
      resolve: (post) => {
        // calcolare qui il valore del path del blog
      },
    },
  },
}));
```

### Computed field `isDraft`

Vi ricordate che nel precedente articolo abbiamo detto che se non è presenta la proprietà `published` allora il post è una bozza.
Possiamo sfruttare computed field per creare un field `isDraft` che è più semplice da comprendere quando si guardano le proprietà
del post:

```ts
export const BlogPost = defineDocumentType(() => ({
  name: "BlogPost",
  filePathPattern: `blog/**/*.(md|mdx)`,
  contentType: "mdx",
  fields: {
    // ...
  },
  computedFields: {
    // ...
    isDraft: {
      type: "boolean",
      resolve: (post) => {
        return !post.date;
      },
    },
  },
}));
```

<InfoBox title="operator `!`">
  Ricordate che l'operatore `!` trasforma un valore in booleano (invertendolo).
  Quindi se la data non è stata impostata, `!post.date` vale `true`, altriment
  `false`.
</InfoBox>

Fatto questo possiamo usare questa nuova proprietà per filtrare dai post che visualizziamo
quelli che sono ancora draft, in questo modo:

```ts
// pages/index.tsx

// ...

export const getStaticProps = async () => {
  // ...
  const posts = allBlogPosts.filter((p) => !p.isDraft).map(getPostFrontmatter);
  return {
    // ...
  };
};
```

### Computed field `path`

Per calcolare il valore del path, ci servono due funzioni di supporto:

- Una funzione chiamiamo `slugify()` che ci calcoli lo slug a partire dal titolo del post,
- Una funzione `computeDate()` che ci calcola la data in formato `yyyy-mm-dd` a partire dalla data del post,

Iniziamo ad implementarle:

#### funzione `slugify`

Ho trovato questa implementazione su interent che sfrutta le [Regex](https://regex101.com/), non è ora molto
importante capire come funziona, in generale quello che fa è trasformare la stringa in caratteri minuscoli,
rimuovere i vari caratteri non alfanumerici e trasformare gli spazi in trattini.

```ts
function slugify(title: string) {
  return title
    .trim()
    .toLowerCase()
    .replace(/\s+/g, "-")
    .replace(/[^\w\-]+/g, "")
    .replace(/\-\-+/g, "-")
    .replace(/^-+/, "")
    .replace(/-+$/, "");
}
```

Ad esempio, se proviamo a lancaire `slugify` passandogli la stringa `Questo è un titolo!` otterremo la stringa `questo-e-un-titolo`.

#### funzione `computeDate`

Questa funzione è meno criptica, quindi vediamo come implementarla.

Il modo più semplice è sfruttare le funzioni `getFullYear()`, `getMonth()` e `getDate()` di Date per ottenere i valori di
anno, mese e giorno alla data che gli passiamo.

Una prima implementazione potrebbe essere questa:

```ts
function computeDate(date: Date) {
  const yyyy = date.getFullYear();
  const mm = date.getMonth();
  const dd = date.getDate();
  return `${yyyy}-${mm}-${dd}`;
}
```

Però qui abbiamo due problemi:

1. `getMonth()` parte da zero, quindi dobbiamo trasformala in `getMonth() + 1` in modo che Gennaio corrisponda a mese `1` ecc.
2. Per mesi e giorni minori di 10, otterremo una stringa nella come `2022-1-5` mentre noi vogliamo `2022-01-05`.

Per risolvere il secondo problema possiamo usare la funzione `padPrefix()` di stringe, che praticamente inseriscono un carattere di riempimento
all'inizio della stringa se questa è più corta di una lunghezza prestabilita. Quindi ad esempio:

```ts
"2".padStart(2, "0"); // "02"
"12".padStart(2, "0"); // "12"
```

Attenzione però che le funzioni ritornano un oggetto di tipo `number`, quindi prima di tutto dobbiamo trasformarlo in stringa con la funzione `String()`.

Ecco quindi la funzione completa

```ts
function computeDate(date: Date) {
  const yyyy = date.getFullYear();
  const mm = String(date.getMonth() + 1).padStart(2, "0");
  const dd = String(date.getDate()).padStart(2, "0");
  return `${yyyy}-${mm}-${dd}`;
}
```

#### `resolve()`

A questo punto abbiamo tutto quello che ci serve per la nostra funzione resolve. Se la data non è impostata restituiamo come path
il valore nella forma `draft-<slug>`, altrimenti quello che abbiamo visto prima `<yyyy>-<mm>-<dd>-<slug>`.

```ts
export const BlogPost = defineDocumentType(() => ({
  // ...
  computedFields: {
    // ...
    path: {
      type: "string",
      resolve: (post) => {
        if (!post.date) {
          return `draft-${post.title}`;
        }
        const date = computeDate(new Date(post.date));
        const slug = slugify(post.title);
        return `${date}-${slug}`;
      },
    },
  },
}));
```

<InfoBox
  type="warn"
  title="Non usare le compute property nelle funzioni `resolve()`"
>
  Attenzione che non possiamo usare la property `isDraft` nella funzione resolve
  (ed in generale non possiamo usare computed property all'interno dei metodi
  resolve perchè non abbiamo garantito il fatto che siano già stati calcolati).
</InfoBox>

## Dynamic Routes per i nostri Blog Post

Siamo pronti a creare la nostra pagina del blog, e per farlo possiamo usare la funzione **dynamic routes** di Next.js.

Iniziamo creando un nuovo file chiamato `pages/blog/[path].tsx`, dove la sintassi `[path]` indica che questa pagina non avrà
un url fisso come nel caso delle altre pagine, ma risponderà a tutti gli URL nella forma `/blog/[path]`.

All'interno di questo file dobbiamo, come al solito, creare una pagina nella forma di un componente React esportato come default,
e usare la funzione `getStaticProps` per ottenere i dati che vogliamo passare alla pagina.

Ci sono però due differenze rispetto ad una pagina statica normale che abbiamo visto fino ad adesso:

1. Dobbiamo esportare una seconda funzione chiamata `getStaticPaths`, che approfondiremo in seguito.
2. La funzione `getStaticProps` prende in ingresso un parametro che corrisponde al valore della stringa `path` della pagina.
   Ad esempio, all'url reale `/blog/post-slug`, il paramtro `path` passato a `getStaticProps` avrà come varlore `post-slug`.

Iniziamo quindi creando una semplice pagina di esempio che renderizza il titolo del post che stiamo visualizzando ottenuto tramite il
valore contenuto in `path`:

```tsx
import { Footer } from "components/footer";
import { Nav } from "components/nav";
import { allBlogPosts } from "contentlayer/generated";
import { GetStaticPropsContext, InferGetStaticPropsType } from "next";

const BlogPostPage = ({
  post,
}: InferGetStaticPropsType<typeof getStaticProps>) => {
  return (
    <div>
      <Nav />
      {post && (
        <article className="max-w-md m-auto">
          <h1>{post.title}</h1>
        </article>
      )}
      <Footer />
    </div>
  );
};

export default BlogPostPage;

export const getStaticPaths = async () => {
  return {
    paths: [],
    fallback: true,
  };
};

export const getStaticProps = async ({
  params,
}: GetStaticPropsContext<{ path: string }>) => {
  const path = params?.path!;
  const post = allBlogPosts.find((post) => post.path === path);
  return {
    props: {
      post: post,
    },
  };
};
```

Come vedete usiamo il parametro `path` per trovare il blog post che ha come `fields` la path che gli arriva dall'url.

Non è però garantito che `post` esista, quindi nel frontend facciamo un render condizionale e stampiamo il contenuto del post solo
in caso questa esista veramente.

Per provarlo, possiamo modificare il componente `PostPreview` realizzato nel precedente capitolo in modo da rimandare alla pagina
del post tramite un link.

```tsx
// ...
import Link from "next/link";

export const PostPreview = (frontmatter: BlogPostFrontMatter) => {
  return (
    <Link href={`/blog/${frontmatter.path}`}>
      <a>
        <div className="shadow-md p-2 hover:ring-2 rounded-md">
          <h2 className="text-lg font-semibold">{frontmatter.title}</h2>
          {frontmatter.date && (
            <time className="text-sm font-light" dateTime={frontmatter.date}>
              {formatDate(new Date(frontmatter.date))}
            </time>
          )}
          <p className="italic mt-2">{frontmatter.description}</p>
        </div>
      </a>
    </Link>
  );
};

// ...
```

A questo punto, dalla nostra homa page dovremmo poter navigare alla pagina del post cliccando sull'anteprima di ognuno, e vedere
visualizzato a video il relativo titolo.

![Pagina blog post 1](./blog1.png)

### Come funziona `getStaticPaths()`

Abbiamo detto che in caso di pagine dinamiche, dobbiamo esportare la funzione `getStaticPaths` per permettere a next di funziona correttamente.
Ma a cosa serve questa funzione?

L'idea è di informare Next della lista di pagine statiche che deve renderizzare, in quanto queste vengono generate da dati a cui
il framework non ha direttamente accesso.

`getStaticPaths()` deve ritornare due informazioni:

1. Un array `paths`, che contiene la lista di tutti i parametri delle pagine da rendererizzare
2. Un flag `fallback` che indica a next, nel caso in cui la pagina che viene visualizzata a runtime non sia contenuta nell'array `paths`,
   se può comunque provare a renderizzare la pagina (a runtime, quindi non avremo più una pagina statica) o se deve semplicementer ritornare `404`.

Impostando `fallback` a `true`, come abbiamo fatto adesso, Next prova comunque a renderizzare la pagina, ed è il motivo per cui
riusciamo in ogni caso a vedere le pagine del post anche se `paths` è un array vuoto.

Se modifichiamo `getStaticPaths` come segue, infatti, vedrete che rimanderà a 404:

```ts
export const getStaticPaths = async () => {
  return {
    paths: [],
    fallback: false,
  };
};
```

![404 not found](./404.png)

Per risolvere questo problema, e avere le pagine dei post statiche, dobbiamo quindi riempire l'array `paths` con i valori
dei parametri che poi vogliamo passare a `getStaticProps`. L'output che vogliamo è una cosa del genere:

```ts
[
  { params: { path: "2022-03-05-il-mio-primo-post" } },
  { params: { path: "2022-04-08-il-mio-secondo-post" } },
];
```

Che possiamo facilmente ottenere facendo un loop su `allBlogPosts` in questo modo:

```ts
export const getStaticPaths = async () => {
  const paths = allBlogPosts.map((post) => ({
    params: {
      path: post.path,
    },
  }));
  return {
    paths: paths,
    fallback: false,
  };
};
```

Con questa implementazione, e settando `fallback` a `false`, siamo sicuri sempre di trovare un post esistente in `getStaticProps`.
Possiamo quindi forzare il post a essere un oggetto vero (con l'operatore `post!`) senza necessariamente fare un check a runtime
come facciamo adesso.

```diff
export const getStaticProps = async ({
  params,
}: GetStaticPropsContext<{ path: string }>) => {
  const path = params?.path!;
  const post = allBlogPosts.find((post) => post.path === path);
  return {
    props: {
-       post: post,
+       post: post!,
    },
  };
};
```

E possiamo quindi togliere il rendering condizionale nel frontend:

```tsx
const BlogPostPage = ({
  post,
}: InferGetStaticPropsType<typeof getStaticProps>) => {
  return (
    <div>
      <Nav />
      <article className="max-w-md m-auto">
        <h1 className="text-2xl text-center font-bold">{post.title}</h1>
      </article>
      <Footer />
    </div>
  );
};
```

### Renderizziamo il `body` del Post

Per renderizzare il `body` del blog possiamo utilizzare la funzione `useMDXComponent` che ci mette a disposizione
contentlayer nella libreria `next-contentlayer/hooks`. Questa funzione prende il body del post e lo renderizza in un
componente React che possiamo facilmente renderizzare nella nostra pagina:

```tsx
// ...
import { useMDXComponent } from "next-contentlayer/hooks";

const BlogPostPage = ({
  post,
}: InferGetStaticPropsType<typeof getStaticProps>) => {
  const Body = useMDXComponent(post.body.code);
  return (
    <div>
      <Nav />
      <article className="max-w-md m-auto">
        <h1 className="text-2xl text-center font-bold">{post.title}</h1>
        <div>
          <Body />
        </div>
      </article>
      <Footer />
    </div>
  );
};
```

Con il seguente risultato:

![Blog Renderizzato](./blog2.png)

Semplice no?

## Cosa abbiamo imparato?

Questo capitolo è stato abbastanza impegnativo ed abbiamo visto alcune feature di contet layer e di NextJS, in particolare.

- come gestire i computed parameters in ContentLayer
- come creare pagine con i dynamic path
- come sfruttare la funzione `getStaticPaths` in NextJS
- come leggere parametri in `getStaticProps` in una pagina dinamica

A questo punto abbiamo tutto le conoscenze e gli strumenti necessari per creare il nostro blog in NextJS. Nel prossimo
capitolo ci concentreremo nell'aggiustare il blog che abbiamo realizzato in modo che sia bello da vedere e contenga tutti i dati
che ci interessano. E saremo quindi pronti a deployarlo.

Il codice scritto in questo capito è disponibile su [GitHub](https://github.com/ludusrusso/next-js-megatutorial/tree/c6)


Completiamo e ordiniamo il nostro blog

Vuoi accedere ad uno sconto?