PD-105 — Revue de Code¶

Résumé¶

Verdict : ⚠️ RÉSERVES

Bonne séparation des responsabilités entre service (permissions/token), store (état + badge), et handlers (orchestration runtime).
Pattern singleton propre dans notificationService.ts (constructeur privé, getInstance, état interne maîtrisé).
Sérialisation du badge via PQueue({ concurrency: 1 }) bien pensée pour éviter les race conditions.
Déduplication présente à plusieurs niveaux (store + handlers), ce qui réduit les incohérences fonctionnelles.
Logs structurés (log/warn/error) avec identifiants de contexte utiles pour le diagnostic.
Aucun any explicite, code globalement lisible et nommage cohérent.

ID	Description	Fichier	Gravité
R-01	Les subscriptions Expo (`addNotificationReceivedListener`, `addNotificationResponseReceivedListener`) ne sont jamais conservées ni nettoyées (`remove()`), risque de fuite mémoire / doubles callbacks après `reset` + `initialize`.	`src/services/notifications/notificationService.ts`	MAJEUR
R-02	`initialize()` enregistre les listeners avant la validation des permissions; en cas de permission refusée, les listeners restent actifs inutilement.	`src/services/notifications/notificationService.ts`	MINEUR
R-03	Plusieurs casts forcés `as NotificationData` sur `notification.request.content.data` sans validation runtime; fragile en mode strict si payload malformé.	`src/services/notifications/handlers.ts`	MAJEUR
R-04	`clearAll()` ne protège pas `Notifications.setBadgeCountAsync(0)` par `try/catch`; une erreur native peut casser le flux de nettoyage.	`src/store/notificationStore.ts`	MINEUR
R-05	Les méthodes handlers n’encadrent pas leurs opérations critiques (`store.addNotification`, `storage.save`, navigation) dans une stratégie d’erreur explicite (wrap + log + fallback).	`src/services/notifications/handlers.ts`	MINEUR

Points solides
Singleton correctement implémenté.
Guard iOS explicite (Platform.OS !== "ios").
Gestion permission/token claire, avec propagation contrôlée du token aux listeners.
Réserves
Les listeners Expo sont ajoutés mais jamais retirés; il faut stocker les EventSubscription et les remove() dans reset() (et idéalement lors d’un re-init).
Ordre d’initialisation à optimiser: demander/valider permissions avant registerNotificationListeners().
throw error dans initialize() est acceptable, mais prévoir une erreur typée pour faciliter la remontée UI.

Points solides
Bonne modélisation Zustand + persist.
Déduplication et validation minimale des champs obligatoires avant mutation.
computeBadge() sérialisé et mécanisme de réconciliation unreadCount vs calcul réel pertinent.
Réserves
clearAll() devrait isoler l’appel natif badge dans un try/catch (comme dans computeBadge()).
Validation métier utile mais partielle; une validation structurée (schema) rendrait le store plus testable/prédictible.
isLoading est défini mais non exploité (bruit de modèle si non utilisé ailleurs).

Points solides
Flux fonctionnel compréhensible: historisation -> marquage lu -> résolution navigation -> fallback.
Fallback de navigation vers centre notifications bien prévu.
Déduplication avant historisation cohérente avec le store.
Réserves
Typage des payloads trop “optimiste” via cast; il manque un parser/guard pour fiabiliser NotificationData.
Pas de bloc try/catch au niveau des handlers publics pour éviter qu’une erreur stockage/store n’interrompe tout le traitement.
_historizeNotification crée receivedAt: new Date(); attention à la sérialisation/rehydratation (Date vs string) selon l’usage ultérieur.

Si tu veux, je peux te proposer un patch ciblé “levée des réserves” (cleanup listeners + payload guard + hardening erreurs) prêt à intégrer.