Propositions d'améliorations techniques

[ivangabriele]

Ce premier post est vivant et évoluera selon les consensus discutés dans les commentaires :

• Conventions
  • Passer aux Conventional Commits
  • Utiliser husky pour forcer le lint (et le typing si TS) des commits
  • Renforcer et automatiser les règles ESLint
• Bonnes Pratiques
  • Utiliser les versions exactes des dépendances dans le package.json
  • Utiliser des named export partout
  • Migrer progressivement vers TypeScript
  • Utiliser les path aliases
• Performances
  • Migrer vers pnpm ou yarn v3
• Refactoring
  • Dépréciations
  • Limiter l'utilisation des useEffect aux hacks DOM
  • Simplifier la logique entre Component State et Redux State
  • Séparer les exports fonctionnels
  • Migrer vers TypeScipt
  • Migrer vers Node v18

---

Conventions

Passer aux Conventional Commits

Status: En discussion.

Pourquoi ? C'est une pratique largement répandue (Angular, Vue, etc) qui permet d'automatiser le version releasing.

Utiliser husky pour forcer le lint (et le typing si TS) des commits

Status: En discussion.

Pourquoi ? Cela prend du sens si conjugué avec des règles de lint un peu plus strictes et permettra d'éviter de récupérer une application frontend qui tourne avec un log plein d'erreurs et de warnings (coté CLI et browser).

Renforcer et automatiser les règles ESLint

Status: En discussion.

Pourquoi ? Pour à la fois normaliser et automatiser le formatage de l'écriture du code. Possible d'atteindre ~90% d'agnostisme (auto-sort des props et import, espacement des lignes, structure des blocks, array et objects, etc).

---

Bonnes Pratiques

Utiliser les versions exactes des dépendances dans le package.json

Status: En discussion.

Pourquoi ? Cela permet de s'assurer de la consistance entre les versions installées peu importe l'environnement.

Utiliser des named export partout

Status: En discussion.

Pourquoi ? Cela facilite la maintenance du code en forçant une consistance entre les noms déclarés et les noms importés, ainsi que le tree shaking. Le default export considéré comme un anti-pattern en ESM lorsque nous migrerons vers ce mode-là.

Migrer progressivement vers TypeScript

Status: En discussion.

Pourquoi ? Un typage plus strict (s'il est correctement respecté) est toujours gagnant sur la maintenabilité à long terme. Il est maintenant possible d'utiliser pleinement SWC pour obtenir des transpilations beaucoup plus rapides. Typescript est beaucoup moins verbeux que JSDoc.

Source: https://madnight.github.io/githut/#/pull_requests/2022/1

Utiliser les path aliases

Status: En discussion.

Pourquoi ? C'est une proposition de "goût". Que ce soit via les resolve.alias dans Webpack ou via les compilerOptions.paths dans TS, cela évite les '../../../api/alert' pour les transformer en @api/alert.

---

Performances

Migrer vers pnpm ou yarn v3

Status: En discussion.

Pourquoi ? À minima pnpm est beaucoup plus rapide. À maxima yarn V3 avec l'option Plug'n'Play permet des sauter l'ensemble des installations JS et de s'assurer d'une consistance absolue des dépendances entre les environnements.

---

Refactoring

Dépréciations

• react-toast-notifications

Limiter l'utilisation des useEffect aux hacks DOM

Status: En discussion.

Simplifier la logique entre Component State et Redux State

Status: En discussion.

Pourquoi ? L'intrication entre les setState() locaux et les Redux store states complexifie la logique et alourdit les composants. L'idée est de limiter les setState() à ce qui n'est que localement impactant et n'utiliser que Redux dispatch() pour tout ce qui impacte plusieurs composants.

Séparer les exports fonctionnels

Status: En discussion.

Pourquoi ? Le but ici est d'éviter au maximum les export d'objets listant des fonctions pour permettre la détection automatique de code mort.

Migrer vers TypeScipt

Status: En discussion.

Migrer vers Node v18

Status: En discussion.