[Doctype] Refactoring des modèles dérivés de Document

[edas]

Nous avons une suite de modèles dérivés de Document.

Ces modèles me posent un problème sur l'architecture. On utilise une classe avec des méthodes statiques qui gardent un état global à toutes les applications. C'est peu évolutif et on touche déjà des limites en créant des méthodes comme copyWithClient() pour contourner le singleton.

Voici ce que je propose :

[ ] Retoucher Document pour transformer toutes les méthodes statiques en méthodes d'instance
[ ] Retirer l'export par défaut de Document pour le transformer en un const document = new Document() et exporter cette instance (toujours la même donc)

En soi c'est rapide à faire et normalement ça devrait être transparent pour tout ce qui utiliser Document. Celui qui veut accéder à la classe maitresse pour en créer une nouvelle instance peut facilement faire ensuite appel à la propriété constructor.

Le problème c'est qu'on a plein de modèles qui dérivent de Document via un simple extends et la même architecture de singleton. Ça veut dire faire la même chose sur tous ces modèles dérivés.
Ces modèles dérivés partagent aussi l'état enregistré dans Document (les index, le client) donc ça veut dire un peu plus de travail pour y faire de la composition. Ca ne devrait toutefois pas être très complexe/long.

L'enjeu c'est qu'il y a beaucoup de classes à modifier ainsi :

Dans Cozy-Libs
[ ] BankTransaction (Transaction)
[ ] File (CozyFile)
[ ] BalanceHistory
[ ] BankAccountStats
[ ] Contact
[ ] BankAccount
[ ] AdministrativeProcedure
[ ] Account
[ ] Group
[ ] Permission
[ ] Application
[ ] examples et docs

Dans Cozy-Banks
[ ] AppSuggestion
[ ] Trigger
[ ] Settings

En comptant 1/2 journée pour Document, 1/2 journée pour la doc, 1 jour de test et revue, puis 5 classes dérivées par jour, ça fait quand même 5 jours de travail.

[y-lohse]

J'ai poussé ce que j'avais commencé a faire (sans le constructor, mais approche similaire) sur c2a2505, au cas ou. J'ai me suis interrompu après avoir pas mal lutté contre des tests qui cassaient.

Comme évoqué ici il y aussi les propriétés statiques des différentes sous-classes à ne pas oublier.

Et enfin, ca sera un breaking change. Avant on pouvait faire:

Document.registerClient(clientInstance)
BankHistory.doSomethingWithClient()

et ca fonctionnait (parce que clientInstance était partagé entre les classes), mais une fois ces changements faits on ne pourra plus (je pense quand meme que c'est un bon changement, mais effectivement il faut prendre le temps de le faire correctement).

[ptbrowne]

As an experiment, I tried to see if adding the cozyClient parameter to method statically would work. https://astexplorer.net/#/gist/c78b1c9f816b0237c2a2a4875c82a33c/a8e66318ba734a8fa59c70ffd58b5986b149395f

[edas]

@y-lohse C'est faisable via un peu de composition, sans casser l'usage existant. Ca ne me parait pas bloquant

@ptbrowne Ca tourne dans ma tête mais je ne suis toujours pas fana de l'idée de méthodes statiques auxquelles on passe une instance cozy-client à chaque appel. Ca te gêne d'avoir une instance pour garder ce genre de choses dans l'état ?

[ptbrowne]

Ca te gêne d'avoir une instance pour garder ce genre de choses dans l'état ?

Non pas vraiment, mais je vois pas quel est l'avantage ? Pour moi l'idée était de simplifier/expliciter les choses en ayant que des méthodes qui ne servent pas du this.