Plan de refactorisation de la logique spécifique LG

Concept

Ce plan vise à refactoriser la logique spécifique LG en séparant les responsabilités entremêlées dans utilsLg.ts, en créant une structure modulaire similaire à Philips pour améliorer la testabilité, la maintenabilité et l'évolutivité. L'objectif est d'isoler les transports, les services métier et les intégrations UI pour faciliter les futures extensions LG.

1. État des lieux

1.1 Monolithe utilsLg

• Toute la logique d'appel à l'API Idcap (chargement du script, singleton, exécution des requêtes) est concentrée dans src/lib/utilsLg.ts, au même titre que le contrôle des applications, de la TV et du HDMI.【F:src/lib/utilsLg.ts†L1-L209】
• Le même fichier expose également la gestion de l'audio, du réseau, des réglages (debug, séquence de boot, sécurité) et la création d'un dialog LG, ce qui mélange des responsabilités de bas niveau (transport Idcap) et de haut niveau (interactions UI/DOM).【F:src/lib/utilsLg.ts†L209-L553】

1.2 Couche métier fortement couplée

• LgIdentifier orchestre des opérations hétérogènes (configuration Idcap, enregistrement d'applications, gestion du hotspot, interaction avec les stores Svelte) directement via utilsLg, ce qui rend le code difficile à tester et à faire évoluer indépendamment.【F:src/lib/classes/platforms/identifier.ts†L11-L65】
• Les lanceurs d'applications et de TV, ainsi que les utilitaires de modales, importent directement des fonctions LG globales au lieu de passer par des interfaces dédiées, augmentant le couplage entre couches UI et logique plateforme.【F:src/lib/classes/platforms/tvLauncher.ts†L1-L18】【F:src/lib/classes/platforms/appLauncher.ts†L1-L59】【F:src/lib/utilsModals.ts†L1-L69】
• Le composant Svelte Idcap ajoute des écouteurs globaux et manipule la logique LG sans encapsulation, ce qui complique la réutilisation et la libération des ressources.【F:src/lib/components/lg/Idcap.svelte†L1-L34】

1.3 Intégration dans le layout et détection de plateforme

• Le layout principal dérive un drapeau isLG pour déclencher des comportements conditionnels, mais ceux-ci restent éparpillés (ex. injection Idcap, gestion du bouton retour), sans couche de coordination dédiée pour LG.【F:src/routes/(connectivity)/+layout.svelte†L106-L173】

1.4 Comparaison avec la structure Philips

• La logique Philips est isolée dans src/lib/philips/ avec des modules par domaine (API, contrôle réseau, hotspot, services d'écoute web, paramètres professionnels). Chaque module encapsule une responsabilité claire et expose des fonctions spécialisées, facilitant le test et la réutilisation.【F:src/lib/philips/networkControl.ts†L1-L157】【F:src/lib/philips/hotspot.ts†L73-L138】
• L'initialisation Philips côté store illustre comment déclencher une configuration spécifique lors de la détection de la plateforme, en s'appuyant sur des modules spécialisés sans référence croisée directe à la couche UI.【F:src/lib/stores/deviceDetailsStore.ts†L1-L92】

2. Enjeux identifiés

• Responsabilités entremêlées : un seul module gère transport, configuration système, état UI et logique métier LG.
• Difficulté de test : l'absence d'abstractions rend complexe l'injection de doublures pour simuler Idcap ou l'environnement DOM.
• Couplage fort avec l'UI : des fonctions de plateforme sont invoquées directement depuis des composants ou utilitaires Svelte, empêchant la mutualisation et compliquant la maintenance.
• Évolutivité limitée : l'ajout de nouvelles capacités LG risque de gonfler davantage utilsLg.ts, contrairement au découpage déjà opéré pour Philips.

3. Vision cible

• Répliquer l'approche modulaire appliquée à Philips : un espace de noms src/lib/lg/ découpé par domaines (transport Idcap, contrôle des applications, audio, réseau, paramètres, intégration UI).
• Exposer des services/objets clairs consommés par les factories (identifier, appLauncher, tvLauncher, etc.) au lieu de fonctions utilitaires globales.
• Limiter les effets de bord (listeners globaux, accès direct au DOM) à des adaptateurs dédiés, permettant un nettoyage explicite.

4. Plan d'action proposé

Phase 1 : Préparation et sécurisation

1. Cartographier les usages en recensant toutes les importations de utilsLg pour définir les frontières fonctionnelles avant extraction.【F:src/lib/utilsLg.ts†L1-L553】【F:src/lib/classes/platforms/identifier.ts†L11-L65】【F:src/lib/classes/platforms/appLauncher.ts†L1-L59】
2. Couverture de tests minimale : créer des tests unitaires ciblant la détection de plateforme et les orchestrations critiques (par exemple autour de LgIdentifier) pour sécuriser la refactorisation.

Phase 2 : Extraction modulaire progressive

3. Créer src/lib/lg/idcap.ts : y déplacer le chargement du script, le singleton et idcapRequest, en exposant des types communs. Les fonctions consommateurs utilisent ce module comme point d'entrée unique.【F:src/lib/utilsLg.ts†L10-L86】
4. Isoler les domaines fonctionnels dans des modules dédiés (ex. appControl.ts, tvControl.ts, audio.ts, network.ts, settings.ts, softap.ts). Chaque module importe idcapRequest et expose uniquement les opérations de son domaine.【F:src/lib/utilsLg.ts†L88-L395】
5. Créer un adaptateur UI (ex. src/lib/lg/ui/dialog.ts) pour addTVLGDialog et la gestion des listeners clavier, afin de séparer clairement logique métier et manipulation du DOM.【F:src/lib/utilsLg.ts†L440-L505】
6. Introduire un point d’entrée (src/lib/lg/index.ts) réexportant les sous-modules pour assurer une transition progressive sans casser les importations existantes.

Phase 3 : Refactoriser les consommateurs

7. Adapter LgIdentifier pour dépendre d’objets/services (LgSystemConfigurator, LgHotspotService, etc.) injectés ou importés depuis src/lib/lg, ce qui facilitera les tests et alignera la structure avec PhilipsIdentifier (basé sur modules spécialisés).【F:src/lib/classes/platforms/identifier.ts†L11-L65】【F:src/lib/philips/hotspot.ts†L73-L138】
8. Mettre à jour les factories (appLauncher, tvLauncher, utilsModals, composants Svelte) pour utiliser les nouveaux modules ou services, en privilégiant des interfaces (ex. LgTvService) plutôt que des fonctions globales.【F:src/lib/classes/platforms/appLauncher.ts†L25-L59】【F:src/lib/classes/platforms/tvLauncher.ts†L13-L18】【F:src/lib/utilsModals.ts†L1-L69】【F:src/lib/components/lg/Idcap.svelte†L1-L34】
9. Encapsuler l’intégration layout : centraliser l’initialisation LG (chargement Idcap, listeners spécifiques) dans un orchestrateur appelé depuis le layout lorsque deviceTypology.isLgTV() est vrai, afin de réduire les TODO et la logique dispersée.【F:src/routes/(connectivity)/+layout.svelte†L106-L173】

Phase 4 : Nettoyage et alignement

10. Supprimer ou réduire utilsLg.ts en conservant uniquement les réexportations temporaires, puis le retirer une fois tous les consommateurs migrés.
11. Documenter la nouvelle architecture (README interne ou ADR) décrivant l’analogie avec Philips et les points d’extension pour d’autres plateformes.
12. Renforcer la validation : ajouter des tests ciblant les nouveaux modules et prévoir des tests end-to-end (ou scripts manuels) pour vérifier les parcours critiques (lancement TV, mute, hotspot).

5. Prochaines étapes recommandées

• Prioriser l’extraction du transport Idcap (risque élevé) puis des modules réseau/hotspot qui impactent la configuration initiale.
• Planifier la migration des composants UI après stabilisation des services afin de limiter les régressions visibles.
• Calquer les conventions de nommage et de structure sur le dossier philips pour faciliter l’onboarding et la maintenance multi-plateforme.【F:src/lib/philips/networkControl.ts†L1-L157】

6. Avancement

• Phase 2 engagée : les modules idcap, appControl, audio, network, settings, tvControl et power sont désormais isolés sous src/lib/lg/, avec un point d’entrée index.ts qui aligne l’arborescence LG sur celle de Philips.【F:src/lib/lg/idcap.ts†L1-L89】【F:src/lib/lg/index.ts†L1-L9】
• Adaptateurs mis à jour : LgIdentifier, LgAppLauncher, LgTvLauncher, les utilitaires de modales et le composant Idcap consomment maintenant les nouveaux services, confirmant la faisabilité de la migration sans dépendre de utilsLg.ts hérité.【F:src/lib/classes/platforms/identifier.ts†L1-L60】【F:src/lib/classes/platforms/appLauncher.ts†L1-L62】【F:src/lib/utilsModals.ts†L1-L52】【F:src/lib/components/lg/Idcap.svelte†L1-L34】
• Orchestrateur de layout : la logique LG spécifique au layout connectivité (écouteur backButton, purge CMS/Directus conditionnelle, synchronisation du store isPurgePolicyDayShift) est désormais encapsulée dans src/lib/lg/orchestrator.ts, le composant Svelte ne faisant plus qu’invoquer cet orchestrateur avec son état courant.【F:src/lib/lg/orchestrator.ts†L1-L198】【F:src/routes/(connectivity)/+layout.svelte†L1-L220】

7. Priorités immédiates

• ✅ Orchestrateur d’initialisation dans le layout : centralisation effectuée via $lib/lg/orchestrator, le layout se contentant désormais de fournir l’état de la page pour déclencher la purge et les listeners LG.【F:src/lib/lg/orchestrator.ts†L1-L198】【F:src/routes/(connectivity)/+layout.svelte†L134-L183】
• Nettoyage des utilitaires historiques : finaliser l’extraction des branches switch LG encore présentes dans utilsModals.ts en s’appuyant sur les services spécialisés (tvControl, appControl), ce qui permettra ensuite de supprimer utilsLg.ts ou de le réduire à une simple façade.【F:src/lib/utilsModals.ts†L75-L238】
• Couverture de test et documentation : ajouter des tests unitaires autour de LgIdentifier/LgTvLauncher et documenter l’orchestrateur afin de sécuriser les fallbacks inter-constructeurs (Vestel/TCL/G4K) avant la suppression complète des reliquats LG historiques.【F:src/lib/classes/platforms/identifier.ts†L16-L39】【F:docs/technique/features/platform-fallback-spec.md†L1-L139】

Diagrammes

---

e-novatis
Date de dernière mise à jour : date inconnue