Persistance côté extension

[ffoodd]

Glossaire

1. Site : domaine et sous-domaine, correspond au hostname dans les portions d’URL (cf. URL Parts ou la doc de URL.hostname sur MDN.

À faire

• [x] Stocker les réglages par site (domaine + sous-domaine) : dans le localStorageService.
• [x] Stocker les derniers réglages appliqués, globalement : dans le localStorageService.
• [x] Gérer l’activation de l’extension par onglet (E) / (F) : dans le main.ts.
• [ ] Gérer l’affichage de l’extension par onglet (A) / (B) / (C) / (D) :
• [ ] Ré-appliquer les réglages quand on ré-injecte la toolbar (injector dans le main.ts).
• [ ] Appliquer les réglages enregistrés globalement lorsqu’on arrive sur un nouveau site pour lequel on n’a pas de réglages enregistrés.

Autre chose que j’aurais manqué ?

Questions

1. Encore un cas à la noix : quand on met à jour l’extension, est-ce qu’on recharge la palette dans les onglets qui l’avaient affichée ?

[ffoodd]

Note pour la suite : avec les avancées du jour, is-opened et current-route sont également stockés par domaine et en global.

S’il faut les réinitialiser à un moment donné, il faudra sans doute prévoir une méthode dédiée.

[ffoodd]

Je pose mes réflexions, c’est pas si simple !

Constats

Quand on passe d’une page / d’un site à l’autre, l’extension ré-injecte la toolbar mais ne peut pas actionner la pastille ni appliquer les réglages.

• L’extension doit envoyer un message au content script (ou un argument ?) pour lui dire de rouvrir la palette (C) : la route et les réglages sont conservés par onglet, donc tout devrait suivre.
  • Mais l’extension doit savoir si elle demande l’ouverture de la palette, donc on doit bien stocker l’état côté extension également (avec l’identifiant de l’onglet). L’application doit envoyer un message à l’extension quand on change de route, ou qu’on ouvre / ferme la palette.
• La pastille visible (A) est l’état par défaut quand on injecte la toolbar, mais les réglages doivent être ré-appliqués : il faut également envoyer un message pour ce cas.

Le cas de la palette en pause — (B) et (D) — sera à gérer quand la PR idoine sera mergée (#220).

Il n’y a a priori pas besoin de stocker autre chose.

Architecture

Il va falloir implémenter un mécanisme qui écoute chrome.runtime.onMessage() dans l’application, qui n’aura pas d’équivalent côté serveur : je pense qu’un service sera approprié, et le pendant serveur se contentera de ne rien faire.

Une fois la messagerie mise en place, comment déclencher des actions dans l’application ? On déclenche un dispatchEvent() pour réagir dans l’app ? Ça paraît le plus opportun car moins de changements à réaliser dans l’app, donc moins d’impact sur la version serveur aussi.

À continuer…

[ffoodd]

J’ai une base qui semble fonctionner sur Edge.

Reste à faire :

• [x] corriger les erreurs Receiving end does not exist qui surgissent ponctuellement. Peut-être faire en sorte que la toolbar envoie un message quand elle est chargée, avant de chercher à ré-échanger des messages ?
• [x] tester sur Firefox :innocent:
• gérer les cas de rechargement en cas de mise à jour, et de déclenchement du bouton d’action de l’extension.
• désactiver les réglages quand on désactive l’extension via le bouton d’action ?

[ffoodd]

Quelques cas tordus à gérer :

• [x] Quand on réactive l’extension, on créé tous les écrans dans la palette… (?)
• [ ] Remettre « en état » : si la palette était en pause, on doit la relancer en pause.
• [ ] Si la page est rechargée (et donc les scripts retirés) : soit on recharge les scripts, soit on change les valeurs stockées.