Notifications For Front¶
Ce document décrit les notifications telles qu'elles doivent être consommées côté front après la migration.
Catalogue exhaustif des types: - Notification catalog
Principes:
- le backend fournit le texte affiché à l'utilisateur
- pour le centre de notifications, le texte affichable est content
- le frontend affiche title et body tels quels pour les push
- le frontend utilise les types et IDs uniquement pour router et mettre à jour l'état local
- il n'y a pas de compatibilité legacy à maintenir côté front sur les anciens types push
Surfaces à gérer¶
Le front reçoit des mises à jour de notification sur 3 surfaces distinctes: - centre de notifications - push mobile - Mercure temps réel métier
Ces surfaces ne servent pas au même usage.
| Surface | Usage front | Source backend | Règle front |
|---|---|---|---|
| Centre de notifications | Lister les notifications utilisateur et les badges associés | API /notifications + Mercure notification |
Afficher la projection telle qu'elle est renvoyée |
| Push mobile | Afficher une alerte système mobile et router au tap | Expo push | Afficher title/body, router avec data.type |
| Mercure métier | Mettre à jour les écrans ouverts en temps réel | Mercure hors centre de notifications | Mettre à jour les vues métier, pas reconstruire des notifications |
Règle d'usage Mercure¶
Il y a bien deux usages de Mercure, et le front doit les traiter séparément:
- Mercure notification: mise à jour du centre de notifications et des badges
- Mercure métier: mise à jour temps réel des conversations, messages, events, people
Règle: - le centre de notifications est piloté par les payloads notification - les écrans métier ouverts sont pilotés par les payloads métier - le front ne doit pas reconstruire une notification centre à partir d'un événement Mercure métier
Événements métier et canaux¶
| Événement métier | Centre notif | Mercure notif | Push | Mercure métier | Ce que le front doit faire |
|---|---|---|---|---|---|
| Nouveau message direct | Oui, notif agrégée | Oui | Oui, newDirectMessage |
Oui | Mettre à jour le centre, les badges, la liste de conversations et la conversation si elle est ouverte |
| Nouveau message solidarité | Oui, notif agrégée | Oui | Oui, newSolidarityMessage |
Oui | Même logique que direct, avec routage solidarité |
| Nouveau message event | Oui, notif agrégée | Oui | Oui, newEventMessage |
Oui | Mettre à jour le centre, les badges et les vues event concernées |
| Nouvelle proposition solidaire reçue | Oui, notif système | Oui | Oui, solidarityProposalReceived |
Non | Mettre à jour le centre, les badges et deeplinker vers la demande / conversation |
| Nouvelle proposition de moov reçue | Oui, notif système | Oui | Oui, eventProposalSent |
Non | Mettre à jour le centre, les badges et deeplinker vers la proposition |
| Proposition de moov convertie | Oui, notif système | Oui | Oui, eventProposalConverted |
Non | Mettre à jour le centre, les badges et deeplinker vers l'event créé |
| Lecture réelle de messages | Oui, mise à jour | Oui | Non | Non | Rafraichir le centre et les badges |
| Ouverture liste conversations directes | Oui, passage en read |
Oui | Non | Non | Rafraichir le centre et les badges |
| Transition profil | Oui, notif système | Oui | Oui, profileStatusChanged |
Oui | Mettre à jour le centre, l'état profil et afficher le push reçu |
Notes:
- les notifications de messages sont agrégées dans le centre: une notification peut porter un count > 1
- unreadNotificationCount représente le nombre de notifications non lues du centre, pas le nombre total de messages non lus
- les flux email ne concernent pas le front mobile/web et ne sont pas documentés ici
Notifications centre¶
Pour le centre de notifications:
- le front consomme l'API /notifications
- le front applique les mises à jour Mercure notification sur cette même projection
- les notifications de messages non lus peuvent rester visibles avec un count > 0 même si leur status est read
- une notification peut aussi porter un payload JSON structuré pour le deeplink / contexte
- le backend renvoie un content affichable pour le centre
- le backend ne renvoie pas de title/body pour le centre
Interprétation attendue:
- status = unread: alerte non encore vue
- status = read: alerte déjà vue
- count: backlog sous-jacent encore présent pour les notifications agrégées
- payload: métadonnées structurées de navigation / contexte, si présentes
- content: texte à afficher tel quel dans le centre
Payloads actuels du centre:
- notifications agrégées de messages:
- kind: "unreadMessages"
- scope: "direct" | "solidarity" | "event"
- notifications profil:
- kind: "profileStatusChanged"
- status: "incomplete" | "pending_review" | "approved" | "denied" | "banned"
- proposition solidaire reçue:
- kind: "solidarityProposalReceived"
- module, requestId, conversationId, eventId, helperPersonId
- proposition de moov reçue:
- kind: "eventProposalSent"
- proposalId, title, senderName, creatorPersonId, creatorPseudo
- organizerStructureId, organizerName si la proposition est portée par une structure
- proposition de moov convertie:
- kind: "eventProposalConverted"
- status: "creator" | "registered" | "waitlisted" | "joinable"
- proposalId, eventId, chosenSlotId, startAt, title
Destinations attendues au clic dans le centre:
- scope = "direct": ouvrir l'inbox unifiée avec filtre direct
- scope = "solidarity": ouvrir l'inbox unifiée avec filtre logistique
- scope = "event": ouvrir l'inbox unifiée avec filtre moovs
- kind = "profileStatusChanged": ouvrir l'écran profil / état du profil
- kind = "solidarityProposalReceived": ouvrir la demande / conversation correspondante
- kind = "eventProposalSent": ouvrir le détail de proposition via proposalId
- kind = "eventProposalConverted": ouvrir l'event créé via eventId
Exemples de content attendus dans le centre:
- direct:
- Vous avez un message de Moover non lu
- Vous avez 3 messages de Moover(s) non lus
- logistique:
- Vous avez un message logistique non lu
- Vous avez 5 messages logistiques non lus
- moovs:
- Vous avez un message de Moov non lu
- Vous avez 2 messages de Moov(s) non lus
- profil:
- Votre profil est incomplet
- Votre profil est en attente de validation
- Votre profil a été validé
- Votre profil a été refusé
- Votre profil a été suspendu
- proposition solidaire:
- Alice vous propose son aide pour l'hébergement
- Alice vous propose son aide pour le covoiturage
- Alice vous propose son aide pour le matériel
- proposition de moov:
- Club Alpha vous propose le moov Badminton mardi. Indiquez vos disponibilités parmi les créneaux proposés.
- Le moov Badminton mardi a été créé. Il aura lieu le 20/04/2026 à 18:00.
- Le moov Badminton mardi a été créé. Il aura lieu le 20/04/2026 à 18:00. Vous avez une place en liste principale.
- Le moov Badminton mardi a été créé. Il aura lieu le 20/04/2026 à 18:00. Vous êtes pour l'instant en liste d'attente.
- Le moov Badminton mardi a été créé. Il aura lieu le 20/04/2026 à 18:00. Vous pouvez encore rejoindre la liste des participants.
Push¶
Le front doit considérer que:
- title et body sont définitifs et affichables
- data.type est un discriminant technique de navigation
- les IDs portés dans data sont la source de vérité pour le deeplink
Le front ne doit pas:
- mapper type -> texte utilisateur
- reconstruire un titre ou un body local
- déduire un contexte métier à partir d'un ancien type large comme newUserMessage
Types push à supporter¶
newDirectMessagenewSolidarityMessagenewEventMessageprofileStatusChangedsolidarityProposalReceivedeventProposalSenteventProposalConverted