Reorganisation du code pour la 2.7

Refhi commented 4 months ago

Refactory roadmap

Gestion des impressions

[x] Mettre startPrinting & co dans son propre fichier
[x] sortir les sous-fonctions de startPrinting
[x] la renommer en printkkchose
[x] créer 3 fonctions d'entrées (pour l'impression d'ordo/cerfa, de courbe, et d'aati).

Gestion de lightObserver

[x] remplacer lightObserver par un waitForElement restructuré pour l'occasion
[x] waitLegacyForElement laissé en place, mais marqué comme deprecated (à remplacer lorsqu'on touche aux fonctions, mais sans plus car nécessite bcp de testing...)

Divers

[x] Scinder le code dans différents fichiers selon les logiques abordées

Abeldvlpr commented 3 months ago

Je commence à bosser un peu dessus sur la branch refactoring J'ai fait un premier commit qui n'inclus chaque contentscript que sur les pages qu'il a besoin de modifier ce qui devrait améliorer un peu les performances.

En terme de réorganisation, l'idée que j'ai c'est de diviser les gros fichiers ou ceux qui ont des fonctions très différentes:

content.js mériterais d'être divisé en utilites.js qui contiendrais toutes nos fonctions utilisées de manière globale (addTweak, lightObserver, getOption etc.) et en transférant les autres fonctions dans le fichier correspondant
searchUpload.js pourrait être amélioré en transférant SearchBoxEntryListener() dans utilites.js et en intégrant chaque addTweak dans le fichier qui correspond à sa page

L'idée serait pour chaque page ou type de page (Consultation, prescription, upload, etc.) un seul fichier qui contient toutes les fonctions associées à cette page et ainsi un manifest.json très ciblé qui n'inclus que certains fichiers sur toutes les pages (utilities.js, companionLink.js,hotkeys.js, keyCommands.js et metrics.js) et tous les autres sur la page qu'il a besoin de modifier uniquement...

C'est une idée comme ca, dis moi ce que tu en penses.

Refhi commented 3 months ago

je comprend mieux ton dernier commit du coup :) quels gains peut-on en attendre en terme de perfs ? (on pourrait peut-être faire un petit benchmark avant de se lancer là-dedans ? Je crois qu'il existe des modules qui permettent ça, ou alors on pourrait passer par afterMutation ?) => mon apprehension est le risque que l'extension soit désactivée pour demander des nouvelles autorisations et/ou qu'on se retrouve avec des fonctions auxquelles on n'aurait pas pensées qui se retrouvent inaccessibles :-/ (je suis peut-être parano)

Pour le refactory, après discussion avec mon frère je rajoute des trucs pour startPrinting et lightObserver (cf. message de tête)

Refhi commented 3 months ago

J'ai fait un benchmark avec https://chromewebstore.google.com/detail/page-load-time/fploionmjgeclbkemipmkogoaohcdbig?hl=fr&utm_source=ext_sidebar En pratique avec/sans WH d'activé, la différence est négligeable (au doigt mouillé, mais faudrait qu'on fasse quelques centaines d'itérations pour être réellement scientifique). Le seul cas où ça semble significatif c'est sur le chargement de l'historique à gauche, qui doit rajouter dans les 500ms.

=> si ça te vas je te propose de laisse tel quel le manifest pour l'instant ? (n'hésite pas à me dire si tu voyais une différence significative de ton côté)

Refhi commented 3 months ago

Bon. J'ai commencé à travailler sur la possible réécriture de la fonction d'attente et ça donne ça lorsqu'on l'appelle :

=> il y aurait 2 nouveautés : 1 - les arguments destructurés (avec {}) qui permettent de passer seulement les arguments qu'on souhaite, et ce, de façon nominative 1 - elementDetector est une fonction async qui retourne une promesse, qu'on peut donc appeler :

avec .then

elementDetector({ selector: '[id^="ContentPlaceHolder1_TreeViewBibliot"]' }).then(addPrintIcon);

ou avec un await si on l'appelle depuis une fonction asynchrone :

(async () => {
    let treeViewBibliotheque = await elementDetector({ selector: '[id^="ContentPlaceHolder1_TreeViewBibliot"]' });
    addPrintIcon();
    // lightObserver('[id^="ContentPlaceHolder1_TreeViewBibliot"]', addPrintIcon);
})();

Refhi commented 3 months ago

@Abeldvlpr Pour la 2.7 ça va surtout être le refactory (n'hésite pas à regarder j'ai jalonné le terrain), mais je pense que ça n'empêche pas de faire les bugfix en attendant.

Force est de constater que je n'arrive pas à me limiter aux PR pour l'évolution du code, donc j'ai fait sauter le verrou. L'idée étant par contre d'essayer de limiter les commits aux petits changements de code facile à individualiser, et de faire des PR dès qu'on fait des choses un peu plus costaud si ça te va

Abeldvlpr commented 3 months ago

Ça roule !

Refhi commented 1 month ago

refactory fait !

Je fais encore quelques tickets avant de pousser une nouvelle version

Refhi / Weda-Helper