# Recommandations Lunatic

L'analyse du code de Lunatic révèle quelques pistes d'amélioration qui permettront d'améliorer la qualité du code. J'ai classé ces recommandations en fonction de la difficulté de mis en place.

## Extension .jsx

**Difficulté :** Simple (à faire quand il n'y a pas de PR en cours)

Le projet utilise actuellement babel qui est configuré pour convertir des fichier JavaScript en les considérant comme des fichiers JSX mais cela n'est pas optimal pour le futur. Il faudrait prévoir de renommer les fichiers React en utilisant .jsx (on peut automatiser ce processus).

## Limiter les export default

**Difficulté :** Simple (à faire quand il n'y a pas de PR en cours)

L'export par défaut est peu pratique car une fois le composant importé le nom peut être changé ce qui rend l'exploration du code plus difficile.

import Button from './button'

On préfèrera en général exporter avec un nom car cela permet d'avoir plusieurs export et d'avoir un alias si nécessaire

import {Button} from './button'
// Dans le cas d'un alias, on a tjrs le nom original, ce qui simplifie la recherche
import {Button as MyButton} from './button'

Cela peut être fait dans un second temps pour les composants existant mais adopté cette stratégie pour les nouveaux composants serait préférable.

## Nommage des fichiers

**Difficulté :** Simple (à faire quand il n'y a pas de PR en cours)

Je ne sais pas si il y a eu une convention sur le nommage des fichiers. Certains fichiers sont préfixés par "lunatic-" et d'autres ne correspondent pas forcément au nom des composants. La convention qui semble adoptée est le "kebab-case", on peut continuer cette convention.

## Commentaires

**Difficulté :** Simple (à faire au fil du temps)

La principal problématique de Lunatic est l'absence de connaissance sur son fonctionnement et le fonctionnement interne du système. Pour réduire cette friction il est impératif d'ajouter des commentaires pour comprendre le rôle des fonctions et des paramètres.

Par exemple :

import camelCase from 'lodash.camelcase';

function buildStyleObject(obj) {
	return obj
		? Object.entries(obj).reduce((_, [key, value]) => {
				if (key.startsWith(':')) _[key] = buildStyleObject(value);
				else _[camelCase(key)] = value;
				return _;
		  }, {})
		: {};
}
export default buildStyleObject;

La lecture du code permet de comprendre en partie ce que fait la fonction mais on ne sait pas pourquoi cette fonction existe, ni pourquoi elle a besoin d'être là.

Il est donc impératif de faire le travail de commenter le code, pas seulement pour décrire le code (ce qui peut se comprendre en le lisant), mais aussi pour décrire son origine / rôle.

En JavaScript il y a une convention pour commenter les fonctions (les paramètres, les types de retours et les erreurs) : [La JSDoc](https://jsdoc.app/).

/**
 * On explique le rôle de la fonction ici 
 * @param {{[key: string]: string}} obj une explication ici
 * @return {StyleHTMLAttributes}
 */
function buildStyleObject(obj) {
	return obj
		? Object.entries(obj).reduce((_, [key, value]) => {
				if (key.startsWith(':')) _[key] = buildStyleObject(value);
				else _[camelCase(key)] = value;
				return _;
		  }, {})
		: {};
}
export default buildStyleObject;

Il est impératif d'écrire ces commentaires car, sans eux, le rôle de la fonction n'est pas évident pour l'équipe.

## TypeScript

**Difficulté :** Complexe (il faut adapter la configuration pour gérer ces types de fichiers)

L'utilisation du TypeScript permettrait une meilleur compréhension des fonctions et permettrait de s'assurer du bon fonctionnement du code même sans tests. Une telle refonte est cependant assez complexe car elle prendra du temps (surtout dans une bonne compréhension du projet).

C'est une réorganisation lourde donc il faut que tous les acteurs du projet soient d'accord avant de lancer ce chantier. La JSDoc pourra être utilisé en attendant.

## Tests unitaires

**Difficulté :** Moyenne (à faire au fil des nouvelles features)

Certaines fonctions simples pourraient être testé unitairement. Cela permet de s'assurer du bon fonctionnement mais offre aussi des informations sur son fonctionnement réel. Si on reprend l'exemple de la fonction `buildStyleObject` vu précédemment des tests auraient permis de comprendre son objectif à travers les exemples donnés.

## Tests fonctionnels

**Difficulté :** Moyenne (à faire au fil des nouvelles features)

Lorsqu'une demande est fait pour une nouvelle fonctionnalité il serait intéréssant de commencer à convertir ces spécification en tests fonctionnels pour pouvoir valider que ce que l'on fait est juste et continue à fonctionner dans le temps. Si on adopte cette stratégie il faudra faire en sorte que ces tests soient simples à écrire (Jest dispose de librairie pour aider en ce sens).