🇬🇧 English
📝 In Short
The red "Error, retry" toast no longer pops up when you navigate to another plugin and back to NotifySync.
🐛 What's Fixed
- Spurious error toast on the admin page — Switching between plugin config pages and returning to NotifySync caused a red error notification, even though the page rendered fine. The load routine is now more resilient and only surfaces errors when there's an actual problem the user needs to act on.
🔧 Technical details for the curious
Two contributing causes, both addressed:
-
Concurrent
load()runs. Jellyfin's SPA can firepageshowmultiple times in quick succession during navigation; two overlappingload()runs race on the sameApiClient+ DOM state and at least one throws. Added anif (this._loading) return;guard at entry, cleared in cleanup. -
Single global try/catch. Any throw from any DOM query or async call cascaded into a single
showToast(CT.errorMsg, 'error')call, even when most of the page rendered fine. Introduced asafe(label, fn)helper that wraps each independent section (renderLibs / renderCollections / renderMap / loadDeletedItems) in its own try/catch — failures are logged to the console but no longer surface as a global toast.
DOM access in the settings panel is now null-guarded (missing elements during SPA re-mount are skipped instead of throwing). The plugin config fetch remains the one required step; if it fails the load aborts gracefully and the loading spinner is dismissed.
Save and refresh-history still toast on success/error as before — those are user-initiated actions that warrant feedback.
🇫🇷 Français
📝 En bref
Le toast rouge "Erreur. Réessayez." n'apparaît plus quand tu navigues vers un autre plugin et reviens sur NotifySync.
🐛 Corrections
- Toast d'erreur parasite sur la page admin — Passer d'une page de config plugin à une autre et revenir sur NotifySync provoquait une notification d'erreur rouge, alors que la page s'affichait correctement. La routine de chargement est maintenant plus résiliente et ne remonte les erreurs que quand il y a un vrai problème actionable.
🔧 Détails techniques pour les curieux
Deux causes contributrices, toutes deux corrigées :
-
Appels
load()concurrents. Le SPA Jellyfin peut déclencherpageshowplusieurs fois en succession rapide pendant la navigation ; deux runsload()qui se chevauchent entrent en course sur le même étatApiClient+ DOM et au moins un throw. Ajout d'un guardif (this._loading) return;en entrée, libéré en cleanup. -
Un seul try/catch global. N'importe quel throw d'une requête DOM ou d'un appel async cascadait dans un seul appel
showToast(CT.errorMsg, 'error'), même quand la majeure partie de la page s'était bien rendue. Introduction d'un helpersafe(label, fn)qui wrappe chaque section indépendante (renderLibs / renderCollections / renderMap / loadDeletedItems) dans son propre try/catch — les échecs sont loggés dans la console mais ne remontent plus en toast global.
Les accès DOM dans le panel settings sont maintenant null-guardés (les éléments manquants pendant un re-mount SPA sont skippés au lieu de throw). Le fetch de config plugin reste la seule étape requise ; s'il échoue le load abort proprement et le spinner de chargement est masqué.
Save et régénération d'historique toastent toujours sur succès/erreur comme avant — ce sont des actions user-initiées qui méritent un feedback.