### Un formulaire d'Upload

Pour tout projet un tant soit peu ambitieux, nous avons besoin de gérer des uploads de fichiers. C'est pourquoi je vous propose aujourd'hui de mettre en place un formulaire d'upload de fichier, sans se prendre la tête avec des extensions et alourdir notre code pour rien. Du vrai Do It Yourself ! 😎

Nous allons utiliser **Next.js 14**, **Typescript** et **React**, mais je vous préviens, je n'ai pas fait de vérifications côté front ou back du contenu, des extensions de fichier autorisées, de la taille maximum, pas de design etc... Ce sont des choses que vous pourrez ajouter facilement par la suite.

Nous allons faire un upload où le serveur renverra le nom du fichier reçu, et nous nous assurerons que ce fichier existe bien côté serveur.

Dans ce cas, nous allons recevoir les uploads directement dans **/public**, afin de pouvoir récupérer les images côté front par la suite.

### Côté serveur

Nous aurons besoin de définir au moins un environnement pour que le **filesystem** sache où écrire.

Je crée un fichier **.env**

```
ROOT_PATH=/var/www/node/next-upload/ # path vers votre projet ici
```

Je crée une route d'API dans **src/app/api/upload/route.ts**

```javascript
import { NextRequest, NextResponse } from "next/server";
import path from "path";
import fs from "fs";

const UPLOAD_DIR = path.resolve(process.env.ROOT_PATH ?? "", "public/uploads");

export const POST = async (req: NextRequest) => {
  const formData = await req.formData();
  const body = Object.fromEntries(formData);
  const file = (body.file as Blob) || null;

  if (file) {
    const buffer = Buffer.from(await file.arrayBuffer());
    if (!fs.existsSync(UPLOAD_DIR)) {
      fs.mkdirSync(UPLOAD_DIR);
    }

    fs.writeFileSync(
      path.resolve(UPLOAD_DIR, (body.file as File).name),
      buffer
    );
  } else {
    return NextResponse.json({
      success: false,
    });
  }

  return NextResponse.json({
    success: true,
    name: (body.file as File).name,
  });
};
```

### Côté front

Je vais créer un fichier **src/components/form.tsx**, nous allons déclencher un upload directement si l'état de l'input file change.

```javascript
"use client";

export const Form = () => {
  return (
    <input
      type="file"
      name="file"
      onChange={async (e) => {
        if (e.target.files) {
          const formData = new FormData();
          Object.values(e.target.files).forEach((file) => {
            formData.append("file", file);
          });

          const response = await fetch("/api/upload", {
            method: "POST",
            body: formData,
          });

          const result = await response.json();
          if (result.success) {
            alert("Upload ok : " + result.name);
          } else {
            alert("Upload failed");
          }
        }
      }}
    />
  );
};
```

Enfin dans **src/app/page.tsx**

```javascript
import { Form } from "@/components/form";

export default function Home() {
  return (
    <main className="flex min-h-screen flex-col items-center justify-between p-24">
      <Form />
    </main>
  );
}
```

Et voilà le résultat :

![upload_small.gif](https://bo.dev-freelance.fr/uploads/upload_small_4ed0182022.gif)

Je ne le dirais jamais assez, il ne faut pas s'encombrer de libs inutiles dans nos projets, si on peut faire sans, faisons sans, et augmentons la valeur de nos produits !



large_upload-form.jpg

medium_upload-form.jpg

small_upload-form.jpg

thumbnail_upload-form.jpg

upload-form.jpg

Aujourd'hui nous allons voir comment faire un upload très simple avec Next.js 14 en App Router, sans extension Formidable, Multer ou autre sorcellerie. Accrochez vous ça va aller vite !

Comment faire un Upload avec Next.js en App Router

## Next.js 12

La mise en place de cette version du blog a commencé sous **Next.js 12**. Grand fan de **Typescript**, ce langage m'a permis d'aller vite, de faire propre, de m'y retrouver facilement et d'être assez _bulletproof_ sur les erreurs. 

Attention, je ne dis pas qu'il n'y en a pas, mais je dis que j'ai dû en éliminer 98% facile. No joke !

**Next.js** est une technologie que j'apprécie beaucoup car j'aime l'approche des composants **React** de manière générale, mais j'aime aussi la philosophie tourné **Dev XP** (c'est à dire l'expérience améliorée pour les développeurs). **Next** permet le server side render (améliorant grandement la **SEO**), et utiliser ses composants **React** de manière **isomorphique** (peu importe que vous soyez en back et en front).

### Etat de la performance sur Next.js 12

J'utilise pas mal de librairies tel que **Marked** pour render le **Markdown**, **Highlight.js** pour la coloration syntaxique, **Charts** et **Mermaid**, tout cela a un poids. Lorsque je compile mon serveur, j'ai les statistiques suivantes:

![2024-05-06_11-50.png](https://bo.dev-freelance.fr/uploads/2024_05_06_11_50_e3a78d621c.png)

Ma page la plus lourde fait **425kb**, cela aura une conséquence sur les temps de chargement. Il faut faire le maximum pour le réduire, mais je ne peux pas aller plus loin, sans me lancer dans une refacto énorme et la réécriture de beaucoup de libs externes.

### Passage à Next.js 14

Lors du passage à **Next.js 14** toujours en **Page Router** afin de ne pas casser la structure, j'ai opté pour la centralisation vers un dossier **src/**. 

Et c'est à peu près le seul changement que j'ai fait, sans compter la mise à jour des paquets tels que **Marked**, **Higlight**, **React-Query**, etc...

**Next.js** lui même a quelque breaking changes entre **12** et **14**, par exemple les **< Link >** qui pendant longtemps servaient à wrapper des **< a href >** sont maintenant des standalones. Donc il a fallu faire quelques légères retouches.

```javascript
// Avant
<Link href="/">
  <a className="w-full mb-4 text-gray-500" title="Aller à l'accueil">
    Accueil
  </a>
</Link>

// Maintenant
<Link
  href="/"
  className="w-full mb-4 text-gray-500"
  title="Aller à l'accueil"
>
  Accueil
</Link>
```

De même, **React-Query** a changé depuis 2 ans. Désormais, le paquet se charge depuis **"@tanstack/react-query"**

React-Query ne permet plus la définition de onSuccess et onError sur les queries, mais uniquement sur les mutations. De plus, les query et mutations se déclarent via un unique argument de type objet, voyez plutôt:

```javascript
// Avant
useQuery(
    ['favorites', linkType, contentId],
    () => fetch(`/api/favorites/${linkType}/${contentId}`).then((res) => res.json()),
    {
      onSuccess: ({ favorite }: { favorite: boolean }) => {
        setFavorite(favorite)
      },
    }
  )
  
  // Maintenant
  const { data, isPending } = useQuery<{ favorite: boolean }>({
    queryKey: ["favorites", linkType, contentId],
    queryFn: () =>
      fetch(`/api/favorites/${linkType}/${contentId}`).then((res) =>
        res.json()
      ),
  });
```

Cela implique l'utilisation de **useEffect** si vous voulez retourner un _state_ une fois que **isPending** sera _false_.

Après les quelques correctifs et un redéploiement, nous obetenons ces stats:

![2024-05-06_12-06.png](https://bo.dev-freelance.fr/uploads/2024_05_06_12_06_b534f298a2.png)

Vous remarquerez qu'ils ont retiré la coloration des **sizes**. Coincidence ?

Alors premier constat, je prends **10kb** avant/après. Pour autant, est-ce dramatique ? 

![2024-05-06_12-12.png](https://bo.dev-freelance.fr/uploads/2024_05_06_12_12_a6ec3687b2.png)



> Et bien la réponse est non ! 

Les networks calls de la page sont toujours aussi rapide à charger, en sachant que je suis **Cache Disabled**. Donc avec l'activation, je vous laisse imaginer le résultat.

Je dois admettre que je suis assez content de cette mise à jour. Vive **Next.js**, vive **Strapi** et surtout vive **Typescript** ! 😍 

large_next_update.jpg

medium_next_update.jpg

small_next_update.jpg

thumbnail_next_update.jpg

next_update.jpg

Voilà, après le back, il faut bien faire le front, il en avait besoin. On passe de Next.js 12 vers 14, toujours en Page Router. Tout ça en moins d'une heure. Accrochez vous !

Mise à jour de Next.js 12 vers 14

## Strapi 4.2.0-beta.3

![update-strapi.png](https://bo.dev-freelance.fr/uploads/update_strapi_ba33f12377.png)

Comme vous pouvez le voir sur ces screenshot, je pars de loin. J'avais adopté **Strapi** à l'époque lorsqu'ils ont publié leur beta de **Typescript**, sans cela, j'aurais passé mon chemin.

Mais je suis un peu obligé de monter de version, non seulement pour profiter des dernières features, mais aussi de la sécurité (et de "stabilité"). Je mets des crochets car j'ai réalisé que beaucoup de choses n'allait pas. Les redirections qui ne fonctionnent pas, etc...

Nous allons en parler dès maintenant 👇👇, afin que cela puisse vous aider à monter de version sur vos backend **Strapi**

### Strapi

Déjà rappelons ce qu'est **Strapi**, il s'agit d'un **Headless CMS**, cela signifie, que c'est un backend pour gérer du contenu. Un demi **Wordpress** quoi, il ne vous reste plus qu'à trouver le frontend qui va bien et on est bon.

Mais pour moi, c'est parfait, je déteste **Wordpress** car beaucoup trop rigide et code ayant peu de sens à mon gout (des **ob_get_contents**, **ob_get_clean**, ...) du buffer dans tous les sens, ce qui fait ce que ce vous voyez en haut d'un fichier peut être rendu en bas, etc... Bref on s'y perd dans un truc pareil, je déteste.

Je préfère 1000 fois partir sur un truc beaucoup plus stable, et afin de ne pas recréer la roue, **Strapi** est là.

Pour le frontend, vous le savez mais je suis parti sur **Next.js** étant un fan de **Typescript**.

### Pour monter de version sur **Strapi**

Aïe ! C'est là où ça se complique. J'ai d'abord essayé une mise à jour via **Strapi** lui même:

```
npx @strapi/upgrade minor
```

Mais impossible, il détectait ma version comme étant la dernière disponible. Peut-être parce que je partais d'une beta, qui sait ?

De même, j'ai essayé de faire un update package à la main dans le repo, sur une branche spécifique, mais non, rien n'y fait.

Je me suis resigné à refaire un repo de A à Z avec la dernière version stable et voir si je peux importer mes models et tout ce qui est custom par la suite.

Donc on repart sur une install complète:

```
yarn create strapi-app my-project --ts
```

Cette approche a fonctionné mais je dois vous mettre en garde, à la "recréation" de la connexion à la base de données, tous les models customs que j'avais créé dans ma précédente version de **Strapi** ont fait un **DROP TABLE**. Je me suis retrouvé avec une base à moitié vide, en tout cas sur mon contenu, ce qui est assez déroutant. Pour les données core de strapi, users, files, etc, rien n'avait bougé.

Heureusement, j'avais des backups donc, ce n'est définitivement pas un problème, mais je tenais à vous le dire pour que vous ne commettiez pas la même erreur. Faîtes un **dump** au cas où, avant de tenter un upgrade.


### Résultat

![upgrade_strapi.png](https://bo.dev-freelance.fr/uploads/upgrade_strapi_c2906be32b.png)

J'ai constaté que quelques pages rencontrent un soucis sur les boutons **Back**, les redirections ne se font plus. Pour la dernière version de la major 4. c'est un peu dommage...

De même, la mise à jour a instauré une régression car, les développeurs ont ajouté une nouvelle colonne sur la table "files", ce qui fait que vous pouvez vous retrouver avec un dossier Media totalement vide sur le backoffice de **Strapi**. Le temps d'un instant j'ai cru qu'il avait tout supprimé.

Mais pas de panique, il suffit de lancer une requête sur votre serveur **PostgreSQL** afin de régler le problème. Cependant, c'est dommage que les développeur n'aient pas pris le temps de mettre une **default value** sur le nouveau champs, d'autant plus si cette valeur était utile pour l'affichage dans le backoffice.

Fixer les fichiers manquants:

```
UPDATE files SET folder_path = '/' WHERE folder_path is NULL;
``` 

Voilà, c'est à peu près tout, la montée de version est faite, tout me semble à peu près ISO. Je crois qu'on a réussi 🙌




large_strapi-update.jpg

medium_strapi-update.jpg

small_strapi-update.jpg

thumbnail_strapi-update.jpg

strapi-update.jpg

Vous le savez peut-être déjà, mais le blog utilise un backend Strapi. Je me suis lancé sur ce dernier, lors des premières versions Typescript en beta 4.2. Mais cela fait 2 ans que je n'y avais pas touché. Il fallait y remédier.

Mise à jour Strapi v4.2.0-Beta.3 vers 4.24.x

### Génération des clés DKIM

En général, je commence par me positionner dans le dossier du projet et je crée un répertoire **dkim** que je prends soin d'ajouter dans **.gitignore**.

Dans ce même répertoire, depuis un terminal, je lance les commandes: 

```bash
openssl genrsa -out dkim-private.pem 1024
openssl rsa -in dkim-private.pem -pubout -out dkim-public.pem
```

Je vais le faire en même temps que vous, je génère des clés de test, et j'ai une clé publique qui ressemble à cela si je fais une lecture avec **cat**:

```bash
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQComXSGZdPfYZOcB1eN1FOxqfSW
CuJoZ8sgkQqP8RR/6YbXhadj4IwUCW/LuUtc5P1IlVDmHSWjYOTiNyfZZknR6Lpf
0Fek3QopucTf4mF+466HMx5B9sryEcrOy011zRtGuONg9wiSxjebzJHqN2C+yRJK
ofYeTm2zplM8YFfLEQIDAQAB
-----END PUBLIC KEY-----
```

Ainsi je génère mes clés **DKIM** que mon process **Node** utilisera pour authentifier que le nom de domaine est bien le mien. Il s'agit d'une signature pour l'envoi de mail, un peu de la même façon que fonctionne votre certificat SSL. 

### Configuration OVH

Maintenant rendez-vous sur votre interface **OVH**.

Dirigeons-nous vers la partie **Web Cloud**, comme ceci:

![01.png](https://bo.dev-freelance.fr/uploads/01_0c99eac1e7.png)

Déroulez vos noms de domaines à gauche, et choisissez celui qui vous intéresse :

![02.png](https://bo.dev-freelance.fr/uploads/02_e861557e08.png)

Maintenant, rendez-vous dans **Zone DNS**: 

![03.png](https://bo.dev-freelance.fr/uploads/03_e91585e4aa.png)

Nous allons ajouter une nouvelle entrée:

![04.png](https://bo.dev-freelance.fr/uploads/04_f98263af09.png)

De type **DKIM**:

![05.png](https://bo.dev-freelance.fr/uploads/05_1cb328eeab.png)

Maintenant vous allez voir un formulaire s'afficher :

![06.png](https://bo.dev-freelance.fr/uploads/06_c6d68a077e.png)

Ici, nous allons :

- Entrer le sous-domaine: **default._domainkey**
- Cocher **version**
- Cocher **type de clé**
- Et dans le textarea Clé publique (base64), nous allons copier coller le contenu de notre clé publique sans les **-----BEGIN PUBLIC KEY-----** et **-----END PUBLIC KEY-----**. On ne copie que le contenu de la clé elle-même. Dans mon cas: 
```bash
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQComXSGZdPfYZOcB1eN1FOxqfSW
CuJoZ8sgkQqP8RR/6YbXhadj4IwUCW/LuUtc5P1IlVDmHSWjYOTiNyfZZknR6Lpf
0Fek3QopucTf4mF+466HMx5B9sryEcrOy011zRtGuONg9wiSxjebzJHqN2C+yRJK
ofYeTm2zplM8YFfLEQIDAQAB
```
- Je valide le formulaire

Une entrée devrait se créer dans votre **Zone DNS**.

### Envoyer des mails avec Typescript

Vous devriez avoir installé **nodemailer** comme ceci:

```bash
yarn add nodemailer
yarn add -D @types/nodemailer
```

Une fois **nodemailer** installé, j'espère que vous avez **Typescript**, si ce n'est pas le cas, je vous recommande mon article qui vous apprend à [bootstraper un projet Typescript](https://dev-freelance.fr/dev/un-projet-backend-typescript-from-scratch).

Je travaille avec dotenv pour ne pas mettre en dur mes configurations, ainsi, à chaque fois que je fais une lib, je peux la copier coller sur tous mes projets.

```
yarn add dotenv
```

Et je configure mes variables dans mon fichier **.env**:

```bash
SMTP_PORT=587
SMTP_USER=contact@xxxx.com
SMTP_PASS= 
SMTP_HOST= 
SMTP_SENDER="Admin <contact@xxxx.com>"
```

Je vais faire une petite lib que j'appelle simplement **mail.ts** dans un dossier **libs**: 

```
import dotenv from "dotenv"
import fs from "fs"
import nodemailer from "nodemailer"
import path from "path"

dotenv.config()
const DKIM_PATH = path.resolve(__dirname, "../dkim")

const transporter = nodemailer.createTransport({
  host: process.env.SMTP_HOST,
  port: Number(process.env.SMTP_PORT),
  secure: false,
  auth: {
    user: process.env.SMTP_USER,
    pass: process.env.SMTP_PASS
  },
  dkim: {
    domainName: "<votre domaine>.com",
    keySelector: "default",
    privateKey: fs.readFileSync(
      path.resolve(DKIM_PATH, "dkim-private.pem"),
      "utf8"
    )
  }
})

export const sendMail = async (
  destinationEmails: string,
  subject: string,
  txt: string,
  html: string
): Promise<string> => {
  try {
    console.log(`Sending mail to: ${destinationEmails}`)

    const info = await transporter.sendMail({
      from: process.env.SMTP_SENDER,
      to: destinationEmails,
      subject: subject,
      text: txt,
      html: html
    })

    console.log("Message sent: %s", info.messageId)

    return info.messageId
  } catch (err) {
    console.error(err)
    throw err
  }
}
```  

Vous pouvez maintenant passer au test dans un fichier test avec Jest, ou faire un simple appel.

```
import { sendMail } from "@/libs/mail"

(async () => {
  const messageId = await sendMail('monemail@domain.com', 'test', 'test', '<html><body><h1>test</h1></body></html>')
  console.log(messageId)
})()
```

Vous devriez non seulement recevoir un email dans votre boite de réception et afficher un **messageId** par la même occasion.

Voilà, j'espère qu'avec ça, vous serez en mesure d'envoyer des mails, et surtout, de ne pas aller dans les spams.

D'ici la prochaine, bon dev à vous 😉


large_dkim.jpg

medium_dkim.jpg

small_dkim.jpg

thumbnail_dkim.jpg

dkim.jpg

Pour envoyer des mails depuis son projet Node, il est fortement recommandé de configurer une clé DKIM afin d'éviter que l'email finisse dans les spams. Je vais vous guider pas à pas afin de mettre en place votre clé DKIM sur votre serveur Linux et comment configurer la clé sur OVH. Enfin, nous utliserons Nodemailer afin d'envoyer des emails avec cette clé DKIM.

Configurer une clé DKIM sur OVH avec Node Mailer

Aujourd'hui nous allons régler un problème rencontré de tous lorsque vous interagissez avec des **API**, l'écriture des routes !

Pour peu que vous codez avec **React** ou **Angular** ou autre et que vous ayez besoin de faire des appels **API**, ce article risque de vous être utile. 

## Comment avons nous l'habitude d'écrire nos routes

Généralement, tout paramètre dans la route est concaténé par nos soins, en veillant à éviter les erreurs de frappes lors de la saisie:

```javascript
const categoryId = 'tech';
const sortBy = 'date';
const order = 'desc';
const endpoint = `http://example.com/api/posts/${categoryId}?sortBy=${sortBy}&order=${order}`;

fetch(endpoint, {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json'
  },
  body: JSON.stringify({
    title: 'New Post',
    content: 'Lorem ipsum dolor sit amet, consectetur adipiscing elit.'
  })
}).then(response => {
  // Traitement de la réponse
}).catch(error => {
  // Gestion des erreurs
});
```

Ce bloc ressemble à quelque chose que je vois souvent dans les projets surtout les lignes:

```javascript
const categoryId = 'tech';
const sortBy = 'date';
const order = 'desc';
const endpoint = `http://example.com/api/posts/${categoryId}?sortBy=${sortBy}&order=${order}`;
```

Ou encore celui-ci: 

```javascript
const groupId = '5678';
const query = 'role=admin';
const endpoint2 = `http://example.com/api/groups/${groupId}/members?${query}`;
```

Donc, je me pose une question: que se passe t-il lorsque les **query parameters** sont optionels ? 

On fait des conditions avant de générer la variable ? 

On est d'accord:

- c'est fastidieux 🥱
- on se répète dès que deux blocs utilisent le même endpoint 😵‍💫
- écrire les **URL** à la main c'est risquer de mal les écrire 😵
- on n'a pas de contrôle sur ce que tape le développeur donc aucun contrôle sur le fait qu'il saisisse une **URL** existante 😓

<u>Dans ce cas, on ne respect ni les principes Kiss, ni les principes DRY.</u>

Je me suis dit, j'ai pas envie de répéter ces lignes pour forger mes routes à chaque fois que j'en ai besoin et j'ai réfléchi à une solution simple pour avoir le contrôle, bénéficier de la puissance de **Typescript**, générer **les routes params** sans efforts, ainsi que pour **les query params**.

J'ai créé **api-route-builder**, une librairie qui enlève cette complexité pour vous. Que vous soyez en **frontend** ou **backend** importe peu, laissez-vous guider...

## Générer automatiquement nos routes d'API

Commençons par l'installer, pour consulter la page npm, cliquez [ici](https://www.npmjs.com/package/api-route-builder).

```bash
npm install api-route-builder
# ou
yarn add api-route-builder
```

Le principe est simple, on commence par déclarer ses routes dans un fichier qui servira de librairie:

```javascript
// src/libs/apiRoutes.ts
import { buildRoutes } from "api-route-builder";

// Define your route paths
type RoutePath = "UsersList" | "UserGet" | "GroupJoin";

type Paths = {
  [K in RoutePath]: string;
};

const paths: Paths = {
  UsersList: "/users",
  UserGet: "/users/:userId",
  GroupJoin: "/groups/:groupId/join",
};

export default buildRoutes<RoutePath>("http://localhost:3000", paths);
```

### Comment utiliser la librairie api-route-builder ?

Ensuite à l'utilisation:

```javascript
apiRoutes.UserGet({ userId: "95dbd66e-c548-4d83-9aca-6087d27e1a87" });

apiRoutes.UsersList(null, { limit: 50, offset: 25 });
```

Au delà de juste générer les routes facilement, on veut surtout bénéficier de l'autocomplete de **Typescript**. Toute la force de l'outil se situe dans le fait de ne rien faire à la main, si ce n'est passer les variables.

![api-route-builder.gif](https://bo.dev-freelance.fr/uploads/api_route_builder_2200e5c1ca.gif)

En espérant que cela vous tiendra à distance des erreurs de saisie. 😋

A bientôt et bon code 😉



large_generer-endoints-api.jpg

medium_generer-endoints-api.jpg

small_generer-endoints-api.jpg

thumbnail_generer-endoints-api.jpg

generer-endoints-api.jpg

Utiliser des concaténations et écrire des urls d'endpoint à la main, c'est un bon moyen d'introduire des erreurs et de se répéter dans le code. Premièrement elle ne respecte pas le principle de simplicité, ni le Don't Repeat Yourself (DRY).

Générer facilement ses endpoints d'API en Typescript

Dans mes missions, j'ai rencontré beaucoup de projets où la structure n'allait pas et où il fallait repasser dessus pour éviter les problèmes de déploiement. 

Les migrations **SQL** sont des fichiers qu'il faut écrire avec précaution car votre base de données est la ressource la plus importante de votre projet.

Le code se remplace, les langages sont interchangeables, que vous passiez par du **PHP**, du **Node**, du **Rust** ou du **Python** ne change absolument rien, en revanche, récupérer vos données en base est le socle sur lequel tout le reste vient s'appuyer.

### Les directions de migration SQL

Certaines librairies tel que **Knex.js** (qui est un query builder) vous suggère de créer vos migrations toujours dans deux directions: **Up** et **Down**.

- **Up** étant la direction qui sert à appliquer votre migration
- **Down** étant la direction qui sert à annuler votre migration

C'est une organisation importante qui sert à revenir en arrière à tout moment.

## Quel est le risque lorsqu'une migration SQL est mal écrite ?

Lorsque vous écrivez des migrations et **Up**/**Down** et que ces requêtes sont mal écrites (souvent en **Down**), vous aurez un problème lorsque vous allez rejouer le **Up**.

![idempotency_db.drawio.png](https://bo.dev-freelance.fr/uploads/idempotency_db_drawio_e929b62b56.png)

Dans cet exemple, 2 ressources sont créés à la migration **Up**, mais une seule est détruite lors de la **Down**.

Au prochain run, voici le résultat:
![idempotency_db_2.drawio.png](https://bo.dev-freelance.fr/uploads/idempotency_db_2_drawio_07481e60c3.png)

Le type n'ayant pas été détruit, il déclenche systématiquement une erreur au retry de la migration **Up**.

### Comment régler ce problème de migration

- Toutes les ressources doivent être détruite lors de la migration **Down**.
- On peut essayer d'utiliser des transactions pour grouper les opérations, car il y a un second risque: 

Lorsque vous effectuez une série de requête dans une migration **Up**, si l'une d'entre elle déclenche une erreur, les opérations d'au dessus sont tout de même appliqués. 

Je vous recommande, d'utiliser une stratégie de **Transaction/Rollback** pour éviter d'écrire partiellement les opérations. 

Le fait de tout grouper dans une **Transaction**, la migration se comportera comme un : <u>"tout ou rien"</u>.

On peut même faire l'équivalent d'un bloc **Try/Catch** en **Postgresql**:

```sql
DO $$
DECLARE
    -- Déclarer les variables nécessaires ici
    amount_to_update NUMERIC := 100;
BEGIN
    -- Commencer la transaction
    BEGIN
        -- Effectuer des opérations SQL ici
        UPDATE account SET balance = balance - amount_to_update WHERE account_id = 123;
        UPDATE account SET balance = balance + amount_to_update WHERE account_id = 456;
        
        -- Si une erreur se produit, déclencher une exception
        EXCEPTION WHEN others THEN
            -- Afficher un message d'erreur
            RAISE NOTICE 'Erreur lors de la mise à jour du compte : %', SQLERRM;
            -- Rollback de la transaction
            ROLLBACK;
            -- Quitter la transaction
            RETURN;
    END;
    
    -- Si tout s'est bien passé, committer la transaction
    COMMIT;
END $$;
```

## Quels sont les points à surveiller lorsque nous écrivons une migration SQL

Lorsque nous écrivons une requête **SQL**, nous devons veiller à l'**idempotency**.

L'**idempotency** ou encore en français l'**idempotence**, c'est le fait de pouvoir effectuer la même opération plusieurs fois avec toujours le même output. Le résultat obtenu ne change pas en fonction du nombre d'appels. Il n'a aucun effet de bord et aucun bug venant de la requête en elle même.

De même, nous devons veiller à ce que les requêtes **down**, déconstruisent bien les requêtes **up**, car un oubli peut causer plusieurs problèmes par la suite.

### L'idempotency pour les requêtes SQL

C'est un principe important lorsque vous écrivez vos requêtes, cela signifie que vous pouvez appeler 10 fois votre migration et que le résultat obtenu sera toujours le même. 

Pour les requêtes de migration, l'**idempotency** est très simple à mettre en place.

```
CREATE TABLE IF NOT EXISTS ...

DROP TABLE IF EXISTS ...
```

De cette manière, la **création** ou le **drop** ne se fera toujours qu'une fois, et si la ressource n'existe pas, cette requête est tout simplement ignorée. 

Cela marche pour bien plus de chose que la création et suppression de table. 

**Vous devez respectez au maximum les principes d'idempotence pour absolument toutes les ressources de votre base de données.** 

Je sais que certains seront sceptiques en se disant, "oui mais je ne peux pas utiliser IF NOT EXISTS pour les types par exemple...". Alors comme cela, non ! Mais il y a une façon de le faire:

```
DO $$
BEGIN
    IF NOT EXISTS (SELECT 1 FROM pg_type WHERE typname = 'my_type') THEN
        CREATE TYPE my_type AS
        (
            --my fields here...
        );
    END IF;
END$$;
```
**Avec une transaction, on peut procéder à des vérifications avant la création du type.**

Dans cette situation, s'ils existent, ils ne seront pas recréés. On évitera ainsi de rencontrer des problèmes de conflits.

## Les migrations modernes 

Aujourd'hui, des **ORM** (**Object-Relational Mapping**) un peu plus modernes comme [Prisma](https://www.prisma.io/) font le travail de vérification des ressources existantes à votre place.

Je ne dirai pas qu'ils font absolument tout, mais cet outil vous évitera de créer pas mal d'erreur en faisant à la main la création des ressources.

L'aspect un peu plus négatif à mon goût mais qui plaira surement à une catégorie de personnes, c'est que cela passe par une syntaxe custom créé pour l'occasion qui se rapproche plus du développement que de la syntaxe de base de données. 

Ce qui signifie à terme, perdre un peu de skill **SQL** pour en faire du code. 

Cela est à mettre sur la balance, je ne me ferme pas d'une technologie ou de l'autre, j'utilise les deux dans mes projets, mais je préfère être clair sur ce point. 

Les développeurs qui utilisent **Prisma** ne sont pas aussi skillés en DB que les développeurs qui écrivent à la main leurs requêtes, à juste titre. 

Si on laisse faire l'abstraction, on perd notre familiarité avec les requêtes **SQL** et on a tendance à oublier les optimisations, comprendre comment sont faits les choses.

J'ai envie de transposer cela à mon expérience de la programmation. Pour vous donner une idée, en 2008 mon projet de Bac+2 était de coder en **C++** un logiciel de gestion de panne distantes sur véhicule **Peugeot 607** via un boîtier **Canbus** en **USB**. Cela implique une programmation de **Socket**, la gestion des **DLLs** et des libs, l'interception des erreurs et enfin lecture de trame et conversion analogique/numérique.

De même en 2012, quand je commençais à travailler, mon langage préféré pour le dev est le **C#**.

J'ai abandonné toutes ces technologies pour le Web, constatant qu'en entreprise, rares étaient les sociétés à investir dans des applications lourdes (nécessitant souvent des licences **Windows** payantes elles aussi) et moins de candidats. 

Aujourd'hui, bien je pense être capable d'en refaire si l'envie me prend, je sais que j'ai beaucoup perdu de ces skills systèmes en utilisant de plus en plus de langages abstraits et haut niveau tels que Typescript.

La différence, c'est qu'aujourd'hui, <u>on ne se passe toujours pas de base de données dans les projets.</u>



large_database_migrations.jpg

medium_database_migrations.jpg

small_database_migrations.jpg

thumbnail_database_migrations.jpg

database_migrations.jpg

Lorsque l'on travaille sur un projet qui communique avec une base de données SQL, on utilise souvent des fichiers de migrations afin que chaque développeur puisse se tenir à jour des changements de structure sur la base de données. Cependant il convient de les écrire efficacement.

Comment écrire ses migrations de base de données PostgreSQL

## Le formState de react-hook-form ne se met jamais à jour

```javascript
const {
    register,
    handleSubmit,
    formState
  } = useForm<PostForm>({
    resolver: zodResolver(postValidationSchema)
  })
```

Vous est-il déjà arrivé d'avoir **errors** toujours vide avec votre resolver ?

Lorsque vous loggez **formState** dans un **useEffect**.

### Commençons par vérifier notre resolver zod

Voici à quoi ressemble mon formulaire:

![zod_form.png](https://bo.dev-freelance.fr/uploads/zod_form_e57743086d.png)

Voici le schéma zod:


```javascript
import { ZodType, z } from "zod"

const isUrl =
  /https?:\/\/(www\.)?[-a-zA-Z0-9@:%._+~#=]{1,256}\.[a-zA-Z0-9()]{1,6}\b([-a-zA-Z0-9()@:%_+.~#?&//=]*)/

export const postValidationSchema: ZodType<PostForm> = z
  .object({
    videoUrl: z
      .string()
      .refine((videoUrl) => {
        if (
          videoUrl.length > 0 &&
          isUrl.test(videoUrl) &&
          (!/youtube(.com|.fr|.co.jp|.co.uk|.be)/.test(videoUrl) ||
            !/watch\?v=[a-zA-Z0-9_]{3,}/.test(videoUrl))
        )
          return false
        return true
      }, "must_be_valid_youtube")
      .optional(),
    message: z
      .string()
      .refine((message) => {
        if (message.length > 0 && isUrl.test(message)) return false
        return true
      }, "no_url_in_message")
      .optional()
  })
  .partial()
```

Avec ce schéma de validation, nous voulons mettre en place les règles suivantes:
- Un utilisateur doit au moins saisir une _videoUrl_ ou un _message_
- La _videoUrl_ est forcément une vidéo provenant de **Youtube**
- Le _message_ ne doit contenir aucune **url**

Puis, nous ajoutons la vérification sur notre bouton de formulaire:

```javascript
<button
    type="submit"
    disabled={!formState.isValid}
  >
  <IoIosSend className="mr-2 text-2xl" />
  Send the message
</button>
```
Maintenant, même si ces règles sont appliqués, les messages d'erreur n'arrivent jamais au formulaire:

```javascript
// que ce soit
{formState.errors?.message && (
  <span className="text-red-700">
    {translate(
      `formState.errors.message.message`,
      lang
    )}
  </span>
)}

// ou encore
{formState.errors?.videoUrl && (
  <span className="text-red-700">
    {translate(
      `formState.errors.videoUrl.message`,
      lang
    )}
  </span>
)}
```

### Où sont passés mes messages d'erreurs ?

Lorsque l'on essait d'afficher les erreurs sur notre formulaire, React-Hook-Form se comporte très bizarrement. Mais rassurez vous, cela n'a rien à voir avec votre schéma **zod** ou **yup**. 

![zod_form_ko.gif](https://bo.dev-freelance.fr/uploads/zod_form_ko_13158d3b33.gif)

Même si cela ne fonctionne pas encore, à ce stade vous n'êtes plus très loin !

### Afficher les messages d'erreur React-Hook-Form correctement

Reprenons notre définition du formulaire:

```javascript
import { PostForm, postValidationSchema } from "@/customTypes/post"
import { zodResolver } from "@hookform/resolvers/zod"
import { SubmitHandler, useForm } from "react-hook-form"

const {
    register,
    handleSubmit,
    formState,
    watch,
    trigger
  } = useForm<PostForm>({
    resolver: zodResolver(postValidationSchema)
  })
```

Cette fois-ci, nous allons ajouter watch et trigger.

**Watch** permettra de déclencher un changement de state à chaque modification de la valeur des champs. Nous pourrons l'utiliser dans un **useEffect**. 

**Trigger** quant à lui, sert à forcer un passage au **resolver**, c'est un vrai douanier !

Utilisons-les comme ceci:

```javascript
React.useEffect(() => {
    const subscription = watch(() => {
      trigger(["message", "videoUrl"])
    })
    return () => subscription.unsubscribe()
  }, [watch, trigger])
```

Et maintenant, à quoi ressemble notre formulaire ?

![zod_form_ok.gif](https://bo.dev-freelance.fr/uploads/zod_form_ok_330339ec6e.gif)

J'ai l'impression que tout est ok 😊.

J'espère que cet article vous aidera car je me suis arraché les cheveux pendant 2 jours pour résoudre cette incohérence. Bon code !

large_react-hook-form-cover.jpg

medium_react-hook-form-cover.jpg

small_react-hook-form-cover.jpg

thumbnail_react-hook-form-cover.jpg

react-hook-form-cover.jpg

Vous est-il déjà arrivé de galérer à ajouter des tests sur vos formulaires avec React-Hook-Form ? Pour peu que vous ayez un test custom à mettre en place, que ce soit avec Yup et la fonction .test ou avec Zod et son .refine. Dans cet article nous allons enfin régler ce problème de formState.

Comment ajouter des validateurs custom sur react-hook-form

### Pour coder efficacement, il faut de bons outils

En développement, si l'on code avec les mauvaises technos, les mauvaises libs, les mauvaises versions, on perd du temps. 

Dans l'idée, on aimerait une base de projet sur laquelle on vient ajouter les briques, histoire d'aller vite.

Dernièrement, je vous partageais mon template pour [créer un projet backend Typescript rapidement](https://dev-freelance.fr/dev/un-projet-backend-typescript-from-scratch). 

Aujourd'hui, je vous propose mon template pour lancer rapidement projet frontend. 

Nous allons partir sur **React** ma librairie frontend préférée. Je me suis lancé à l'époque en 2016, sur les conseils d'un ami, [Kevin Vavelin](https://www.linkedin.com/in/kevinvavelin/) qui est un des pionnier de la techno en France. Vous pouvez aussi faire appel à [ses services de développeur, si vous avez un projet.](https://codetics.fr/)

Depuis, je n'ai jamais lâché cette technologie, qui colle énormément à ma personnalité et ma vision du frontend.

### Un projet React Typescript

Je l'ai dis il y a quelques années, **Javascript** pour moi, ce n'est plus possible, j'ai totalement arrêté au profit de **Typescript**. Et je vais être cache, je pense que le gain de temps avec **Typescript**, lorsque le projet commence à devenir de plus en plus complexe, est de 25% à 50% au bas mot. Etant donné que votre IDE vous affichera immédiatement les incohérences, cela vous permet de vous concentrer plus sur le code, et limiter vos scénarios de test à des cas simples.

Si vous n'avez pas encore franchi le pas, je vous laisse vous renseigner, mais pour avoir fait les deux et pour maîtriser les deux, je vous garantie que continuer en **JS**, c'est perdre du temps (après si vous aimez ça... 😂).

Nous allons créer ce projet étape par étape, suivez le guide !

Pourquoi ne pas partager un repository directement ? 🤔

- Premièrement, cela va verrouiller les versions des dépendances et il va falloir le maintenir le repo, je ne trouve pas cette approche intéressante.
- Puis, je pense que de décomposer le déploiement permettra à tout le monde d'ajouter une partie à son projet existant.

Avant d'aller plus loin, sachez que je travaille en **Node v20**, je vous laisse faire les installation avec votre **nvm** préféré. 😋

Nous allons utiliser les technologies suivantes: 
- Typescript
- React.js
- Tailwind
- React-Query
- React-Hook-Form
- Jest
- SWC

### Créer un projet Typescript avec Create-React-App

```shell
yarn create react-app <project-name> --template typescript
cd <project-name>
```

### Installation de Tailwind CSS

**Tailwind CSS** c'est un peu comme si vous utilisiez un aspirateur aujourd'hui au lieu de passer le balai. L'un n'empêche pas l'autre, mais non seulement l'aspirateur aspire la poussière, le balai la déplace. 

De la même manière, **Tailwind** fait tout ce que fait votre CSS, en ayant déjà packagé plusieurs règles CSS dans des classes, sans pour autant guider votre charte graphique comme le ferai un **Bootstrap** ou autre framework graphique.

```shell
yarn add -D tailwindcss
```

Nous allons maintenant générer notre fichier de configuration **Tailwind**:

```shell
npx tailwindcss init
```

Dans **tailwind.config.js**:

```javascript
/** @type {import('tailwindcss').Config} */
module.exports = {
  content: [
    "./src/**/*.{js,jsx,ts,tsx}",
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}
```

Dans **index.css**:

```css
@tailwind base;
@tailwind components;
@tailwind utilities;
```

### Installation de Jest et SWC

**Jest** sert à tester votre projet, que ce soit un projet **backend** ou un projet **frontend**. Il est capable de tester les deux à condition de l'installer et de le configurer correctement.

**SWC** qui signifie **Speedy Web Compiler** est un projet **Rust** qui va nous aider à convertir nos sources Typescript en code Javascript pour que Jest puisse l'interpréter. Une simple conversion standard est beaucoup plus longue. <u>Les maintainers parlent de 20x plus rapide en single core et 70x plus rapide en quad core.</u>

```shell
yarn add -D jest @swc/core @swc/jest ts-node jest-environment-jsdom jest-transform-stub 
```

Création du fichier de configuration de **Jest**:

```shell
npx jest --init
``` 

Lors de votre configuration de **Jest**, choisissez <u>jsdom</u> au lieu de **node**, pour le reste, le défaut convient.

Dans le fichier **jest.config.js**:

```javascript
module.exports = {
  transform: {
    '^.+\\.(t|j)sx?$': '@swc/jest',
    ".+\\.(svg|css|styl|less|sass|scss|png|jpg|ttf|woff|woff2)$":
      "jest-transform-stub",
  },
}
```

Dans vos fichiers de tests, soyez sûr d'ajouter:

```javascript
import "@testing-library/jest-dom";
```

Par exemple, voici mon **App.test.tsx** après modifications:  

```javascript
import React from "react";
import "@testing-library/jest-dom";
import { render, screen } from "@testing-library/react";
import App from "./App";

test("renders learn react link", () => {
  render(<App />);
  const linkElement = screen.getByText(/learn react/i);
  expect(linkElement).toBeInTheDocument();
});
```

Pour lancer les tests, il ne vous reste plus qu'à exécuter:

```shell
npx jest
``` 

### Utiliser des paths alias Typescript avec React

Les paths alias, c'est quoi ?

Et bien, lorsque vous voulez importer vos librairies et composants depuis votre page React, il arrive que vous ayez besoin de parcourir le file system. Pour vous éviter à résolve chaque path de manière relative et que votre code ressemble à cela:

```javascript
import ButtonCustom from '../../components/buttons/ButtonCustom';
...
``` 

Vous pouvez utiliser des paths alias qui vous permettrons de gérer les imports depuis des paths absolus beaucoup plus simples:

```javascript
import ButtonCustom from '@/components/buttons/ButtonCustom';
...
```

Et pour faire cela, rien de plus simple, il vous faut modifier votre fichier **tsconfig.json**:

```javascript
"compilerOptions": {
    // ...
    "paths": {
      "@/*": ["./src/*"]
    },
```

Mais, ce n'est pas terminé ! 

**Create-React-App**, ne peut pas résoudre ces chemins vers vos fichiers directement, il lui faut une surcharge de configuration initiale. Désormais, cette fonctionnalité appartient à une autre package: **Craco** (Create React App Configuration Override):

```shell
yarn add -D @craco/craco
```

Dans un fichier **craco.config.js**, à la racine de votre projet, ajoutez les lignes suivantes:

```javascript
const path = require("path");
module.exports = {
  webpack: {
    alias: {
      "@": path.resolve(__dirname, "src"),
    },
  },
};
```

Et dans votre fichier **package.json** remplacez votre bloc **scripts** par celui-ci:

```javascript
  "scripts": {
    "start": "craco start",
    "build": "craco build",
    "test": "craco test",
    "eject": "craco eject"
  },
  ```
  
### Installation des dernières dépendances

Voici les derniers packages que j'installe sur mes projets front:

- React-Query pour sa simplification de requêtes et son caching key
- ClassNames pour gérer les classes conditionnels
- React-Hook-Form pour simplifier la gestion des formulaires

```shell
yarn add react-query classnames  react-hook-form 
```

Et pour la mise en forme, j'utilise les paquets suivants:

```shell
yarn add -D prettier @trivago/prettier-plugin-sort-imports
```

Dans un fichier **.prettierrc** à la racine, ajoutez les lignes suivantes:

```javascript
{
  "importOrder": ["^components/(.*)$", "^[./]"],
  "importOrderSeparation": true,
  "importOrderSortSpecifiers": true,
  "plugins": ["@trivago/prettier-plugin-sort-imports"]
}
``` 

Maintenant, il vous reste à installer un **React-Router-Dom** si vous voulez créer un système de pages, et autres librairies que vous souhaitez utiliser. 

J'espère vous avoir fait gagner du temps "partenaire !" 🤠 

large_template-frontend.jpg

medium_template-frontend.jpg

small_template-frontend.jpg

thumbnail_template-frontend.jpg

template-frontend.jpg

Je vous donne mon template perso pour déployer un projet React Typescript en moins de temps qu'il ne faut pour lire le nombre de techno que ça embarque. 😂

Un template frontend React Typescript

### Redis n'est plus sous licence open source

![redis-logo.png](https://bo.dev-freelance.fr/uploads/redis_logo_ac9ef3d8fb.png)

**Redis**, désormais détenu par une société commerciale a vu sa licence changer de forme. Il se trouve que dans son code source, il y avait également la participation de la communauté du libre. 

Du jour au lendemain ce code source s'est retrouvé sous le joug d'une société qui, désormais, l'exploite uniquement à ses fins. 

Le problème qu'il s'est passé, ce n'est pas d'essayer de faire le l'argent en tant que société. 

Moi même, je suis développeur et je suis bien placé pour savoir qu'à un moment donné il faut valoriser son travail qui a demandé des efforts de conception/réalisation. Mais lorsque des gens interviennent bénévolement pendant des années afin de faire évoluer le projet, s'approprier leur travail gratuitement, c'est du vol.

La communauté du libre n'a pas tardé à s'organiser.

### La naissance du projet Redict

![redict-logo.svg](https://bo.dev-freelance.fr/uploads/redict_logo_64df6171d3.svg)

**Redict** pour **RE**mote **DICT**ionary a été créé sous licence **LGPL 3.0** par la communauté du libre.

Le projet **Redis**, je connais bien. J'ai de nombreux projets qui s'en servent et Dieu sait que même ce blog s'appuie sur **Redis**. 

Je vais migrer dès que je peux sur **Redict** et l'objectif de cet article est de voir s'il y a moyen de remplacer ce service en fournissant le moins d'efforts possible.

Dans cet article nous allons installer Redict via docker, puis nous effectuerons un test simple d'écriture et lecture. Enfin, je ferai un test local du moteur de blog et nous verrons si Redict est totalement compatible avec les manipulations plus complexes (pattern de clé etc...).

### Installation de Redict via Docker

Je me crée un dossier **redict-test**, et dans un fichier **docker-compose.yml**:

```shell
version: "3.1"

services:
  db:
    image: registry.redict.io/redict
    restart: always
    ports:
      - 6379:6379
```

Une fois le fichier créé, on peu lancer le service: 

```shell
sudo docker compose up -d
```

Nous pouvons vérifier son bon fonctionnement en temps réel:

```shell
sudo watch docker compose ps
```

### Test de Redict avec Node.js

Nous allons créer un projet simple en Node.js Typescript (je ne fais plus de Javascript), mais pas de panique, vous allez voir c'est tout aussi simple. Suivez le guide !

Création d'un **package.json** et ajout des dépendances:

```shell
yarn init

yarn add redis
yarn add typescript @types/node ts-node -D
```

Nous pouvons maintenant créer un fichier, **index.ts**:

```js
import { createClient } from "redis";

(async () => {
  const client = await createClient({
    url: "redis://127.0.0.1:6379",
  })
    .on("error", (err) => console.log("Redis Client Error", err))
    .connect();

  await client.set("key", `value ${Date.now()}`);
  const value = await client.get("key");
  console.log(value);
  await client.disconnect();
})();
``` 

Pour lancer, nous avons juste besoin d'entrer:

```shell
npx ts-node index.ts
```

Nous devrions obtenir le résultat suivant:

```shell
value 1712480118619
```

Victoire ! 🎉🎉

Je tiens tout de même à préciser, que nous pouvons utiliser **redis-cli**, comme nous le faisions habituellement avec **Redis**.

Vu que tout semble ok pour un besoin simple de lecture/écriture, essayons de répondre à un besoin plus complexe.

### Mettre le cache lifecycle du blog sur Redict

Je mets en place mon blog en local avec un dump des articles en ligne. 

<u>Nous n'avons aucun changement à faire au niveau des libs, ni même des variables d'environnement.</u>

Je lance un **monitor** sur un **redis-cli** qui se connecte au serveur **Redict**, et voici ce qu'il se passe lorsque je navigue sur le site:

![redict.gif](https://bo.dev-freelance.fr/uploads/redict_2112928dc8.gif)

Tout semble fonctionner à l'identique, je crois que nous avons réussi ! 🥳

Il ne me reste plus qu'à lancer le chantier en production.


large_redict-cover.jpg

medium_redict-cover.jpg

small_redict-cover.jpg

thumbnail_redict-cover.jpg

redict-cover.jpg

Redis, la base de données en RAM qui fonctionne en clé-valeur a changé de licence dernièrement. Fini le BSD, bonjour le copyright. C'est un move qui a légèrement agacé la communauté de la Tech.

Découvrez tous nos articles de la catégorie Dev - page 1 sur 7