Séparer la vue de la logique / Adopter architecture 3 tiers

[rakruk]

Action plan:

• Créer un service "kalimba" qui ne s'occupera que de copier l'API existante des websockets, c'est la seule classe qui aura accès à auth.service. (15min ~ 45min)
• Créer un service "persistentData" qui ne s'occupera d'interfacer avec localStorage, c'est la seule classe qui pourra faire des appels à localStorage. (10min ~ 30min)
• Créer des services qui contiennent comme variables publiques des données de la DB (par exemple voteService.votes), des transformations utiles qu'on peut réutiliser avec ces components (par exemple voteService.computeScores()) et des méthodes d'appels pour modifier ces trucs (p.e. voteService.setScore()). (30min ~ 1h30)
• Enlever toutes les injections de auth.service des components, remplacer ça par des appels aux services (4h~8h)
• Enlever tous les appels à localStorage des components, replacer ca par des appels aux services (1h~2h)

[rakruk]

@Ithyx @hvdbm Vous en pensez quoi?

[Ithyx]

Sur papier c'est pas mal, mais je pense que tu sous-estime pas mal le temps nécessaire pour chaque tâche, c'est beaucoup de travail, en particulier pour notre flow d'authentification. à voir avec @hvdbm

[hvdbm]

C'est bien plus propre et flexible que ce qu'on a actuellement (qui est un peu bric et broc) mais j'ai aussi l'impression que ça va demander plus de temps qu'estimé.

Il va falloir en plus du voteService d'autres services pour gérer les autres propriétés (ex: les utilisateurs, les chansons, les favoris, etc). Il faudra voir comment on veut adapter ça pour les pages en dehors des constitutions qui font appel au ws (la page des currents constitutions / les pages admin / la page des utilisateurs). Je me pose aussi des questions sur comment on va gérer le timing de certaines requêtes (avoir seulement les votes de l'utilisateur vs tous les votes).

À voir aussi comment on va faire pour gérer les différents types de constitutions (au lieu d'avoir un component global il faudra peut-être en avoir un de chaque type?). Il faudra bien faire attention de comment on va diviser l'issue pour pas se retrouver avec un monstre de PR dont on sera pas capable de bien vérifier qu'on a rien brisé.

Avant toute chose, on devrait merge les PR suivantes qui font un peu de refactor histoire de partir sur une bonne base :

• Refactorisé et modifié la logique de tri des chansons #86
• Ajout du support pour des chansons provenant de Soundcloud #88

[rakruk]

Dommage que github n'ait pas de notions d'epics car ça en ferait un bon 🤭

[hvdbm]

Dommage que github n'ait pas de notions d'epics car ça en ferait un bon

Il y les milestones si on veut. Il faudra juste faire les issues.