Refonte globale de l'architecture

[EmileRolley]

Problématique

Techniquement ce projet est un fork de ekofest. J'ai fait ce choix afin d'avoir très rapidement de quoi faire des tests utilisateurices. En effet, cela a permis d'avoir un MVP en 3/4 jours car le code était suffisamment orthogonale pour fonctionner avec un modèle Publicodes arbitraire.

Cependant, l'organisation du code a évolué de façon très organique et on se retrouve avec une assez forte concentration du code dans quelques modules.

Il serait nécessaire afin d'améliorer la maintenabilité et l'embarquement de nouvelle personnes de faire une refonte globale du projet.

Solution envisagée

Dans le cas de ce projet je pense qu'une solution pertinente serait d'utiliser le framework Elm Land. En effet, ayant conscience qu'Elm est un langage assez peu répandu (bien que quelques projets Beta l'utilisent), je pense qu'il est nécessaire de s'accorder sur une façon standard de développer le projet. Elm land offre ce cadre avec des guides pouvant servir de référentiel pour ajouter un nouveau composant, une nouvelle feature, etc...

Le seul point interrogation actuelle sur son utilisation et le fait que le simulateur utilisant Publicodes doit faire pas mal de FFI et même utiliser un custom component avec React pour la documentation.

Il faudrait donc au préalable vérifier que cela se fait sans trop de difficulté avec Elm Land.

Tasks

Preview Give feedback

1. Tester la possibilité de facilement utiliser des custom components avec React dans Elm Land
2. Si concluant, réécrire le code actuel à partir d'un projet Elm Land
3. Header
4. Home
5. Simulateur
6. Result
7. Documentation

Note à propos du choix d'Elm

Le choix d'utiliser Elm a été fait en partie pour les questions pratiques évoquées plus haut, mais également pour une question politique.

En effet, en choisissant Elm, je favorise mon plaisir au profit de la productivité (même si cela pourrait être contesté par le fait que d'une certaine façon Elm permet d'être plus productif en facilitant les refactoring ainsi que réduire les erreurs au runtime). De plus, la dernière publication du compilateur date de octobre 2019. Cela pourrait faire peur de s'engager sur un langage qui ne semble pas maintenu, or selon moi, au contraire cela est signe d'une certaine maturité et surtout stabilité. Cela s'inscrit également dans une philosophie d'avoir un langage avec fondamentalement peut de fonctionnalités, ce qui permet de rapidement l'apprendre et comprendre le code écrit par d'autres.

En écrivant du Elm, je réduis ma fatigue mentale à devoir choisir toute une stack : pas besoin d'un router spécifique, d'une libraire pour gérer le state de l'application, d'utiliser une nouvelle syntaxe pour écrire des composants, d'avoir tout une batterie de test pour m'assurer de ne pas avoir d'erreur à l'exécution, etc... En effet, en Elm tout se fait directement dans le langage. Le périmètre est défini est restreint : créer des interfaces web interactives, ni plus, ni moins.

J'utilise donc un outil pour une tâche précise, qui me procure du plaisir à utiliser, qui est explicite sur ce qu'il fait (pas d'effets de bords, de structures de contrôles implicites), qui n'est pas dans une courses effrénée d'ajout de nouvelles features et de nouveautés, le tout appartenant à des GAFAMs.

Pour faire un projet d'utilité public ayant pour objectif (en partie) de changer de modèle de société, je pense que c'est bien d'essayer de se passer des outils qui ont été conçu et utilisés par celleux qui sont à l'origine d'une partie du problème. Le choix de nos outils n'est pas neutre 💚

A noter, que je me suis permis de faire ce choix car je suis seul à travailler sur cette base de code. Dans le cas contraire, une concertation en équipe préalable aurait dû être faite, et les choix technologiques auraient certainement été différents.