Navigation et écrans

L'application mobile utilise React Navigation 7 avec deux types de navigateurs : des piles natives (createNativeStackNavigator) et une barre d'onglets (createBottomTabNavigator) dessinée par un composant maison. Tous les en-têtes natifs sont masqués (headerShown: false) : chaque écran affiche son propre en-tête avec ScreenHeader et, si besoin, un bouton retour.

Les trois navigateurs sont dans mobile-app/src/navigation. Leurs paramètres sont typés dans mobile-app/src/types/navigation.types.ts, et mobile-app/src/navigation/hooks.ts fournit deux hooks typés :

Les écrans ne reçoivent plus de prop navigation: any : un nom de route ou un paramètre erroné est refusé par npm run typecheck.

#Arbre de navigation

flowchart TD
  ROOT["RootNavigator : pile racine"] -->|"isAuthenticated faux"| AUTH["AuthStack"]
  ROOT -->|"isAuthenticated vrai"| MAIN["Main : MainTabs"]
  ROOT -->|"connecté ou non"| LEGAL["Legal : documents légaux"]
  ROOT --> PUSH["Écrans empilés : BuyTicket, GiftTicket, WaitingRoom, LiveDraw, TransactionHistory, Notifications, HowItWorks, RewardsCatalog, RewardDetail, ScratchCard, MyCodes, VerifyAge, Settings, DisplaySettings, NotificationSettings, PersonalData, Security, ChangeEmail, ChangePassword, Setup2FA, HelpSupport"]
  AUTH --> A1["Onboarding"]
  AUTH --> A2["SignIn, SignUp"]
  AUTH --> A3["Verify2FA"]
  AUTH --> A4["ForgotPassword, ResetPassword"]
  AUTH --> A5["Setup2FA"]
  MAIN --> T1["HomeTab : HomeScreen"]
  MAIN --> T2["TicketsTab : MyTicketsScreen"]
  MAIN --> T3["SponsorsTab : SponsorsScreen"]
  MAIN --> T4["ProfileTab : ProfileScreen"]

#RootNavigator

RootNavigator.tsx contient le NavigationContainer et une pile racine dont le contenu dépend de state.auth.isAuthenticated :

Ce rendu conditionnel est le mécanisme de garde : quand setCredentials passe isAuthenticated à vrai, React Navigation démonte l'AuthStack et affiche les onglets ; logout fait l'inverse. Aucune navigation explicite n'est nécessaire après la connexion.

Tous les écrans secondaires sont poussés sur cette pile racine : ils s'affichent en plein écran, sans barre d'onglets, et le retour ramène à l'onglet d'origine. Il n'y a plus de pile imbriquée dans un onglet.

#Ouverture automatique de la vérification d'âge

Après la connexion, RootNavigator ouvre de lui-même l'écran VerifyAge quand le profil stocké indique ageVerificationStatus égal à NONE ou REJECTED. La fonction promptAgeVerification est appelée 400 ms après le passage à l'état connecté et à onReady du conteneur. Une référence agePromptShown limite l'ouverture à une fois par session ; elle est remise à zéro à la déconnexion. Un statut PENDING ou VERIFIED n'ouvre rien. Le citoyen peut fermer l'écran : l'achat, le cadeau et les échanges lui seront alors refusés par le backend (403 AGE_VERIFICATION_REQUIRED), et chaque écran concerné propose de rouvrir VerifyAge (voir Portefeuille et loterie).

#Fenêtres globales

RootNavigator rend aussi, au-dessus de la navigation, un bandeau de notification simulé et quatre ResultDialog pilotés par le slice ui : points crédités, réseau encombré, forte affluence et information réseau (voir État et appels API).

#AuthStack

AuthStack.tsx démarre sur Onboarding si hasSeenOnboarding est faux, sinon sur SignIn. hasSeenOnboarding n'est pas persisté : l'introduction réapparaît à chaque démarrage à froid de l'application.

Setup2FA est enregistré dans cette pile, mais aucun écran non connecté n'y mène et l'écran exige un utilisateur connecté pour fonctionner.

#MainTabs

MainTabs.tsx déclare quatre onglets avec des libellés traduits :

La barre TabBar remplace celle de React Navigation : fond surface aux coins supérieurs arrondis (24), ombre portée, icône SVG au-dessus du libellé, onglet actif sur fond sunNav avec icône et texte onSun en gras. Sous les onglets, SecurityFooter rappelle « Application sécurisée · Aucun argent réel ». La marge basse suit l'encart de sécurité de l'appareil.

La rangée porte accessibilityRole="tablist" et chaque onglet accessibilityRole="tab", accessibilityState={{ selected }} et son libellé : les lecteurs d'écran annoncent l'onglet sélectionné. TabBar émet l'événement tabPress avant de naviguer, comme la barre standard, mais ne gère pas l'appui long.

#Les 32 écrans

#Avant connexion

#Onglets

#Écrans empilés

Toutes les routes appelées depuis les écrans connectés exigent un jeton, sauf GET /lottery/status, /leaderboard, /transparency-charter, GET /marketplace/catalog et /rewards/:id, qui sont publiques. Le rôle n'est pas vérifié côté mobile : l'application ne propose aucun écran réservé à ADMIN ou PARTNER. Un compte Mairie ou partenaire qui se connecte voit l'interface citoyenne.

Legal est déclaré dans la pile racine en dehors de la condition isAuthenticated : il s'ouvre aussi bien depuis l'inscription, avant toute connexion, que depuis Aide & Support. Les six documents (CGU, règlement de participation, mentions légales, politique de confidentialité, politique relative aux traceurs, charte de transparence) sont embarqués dans l'application et ne demandent aucun appel réseau.

#Boutons d'en-tête et paramètres

HeaderActions.tsx regroupe deux boutons ronds : la cloche NotificationButton, avec sa pastille quand unreadCount est positif, qui ouvre Notifications, et une roue dentée (icône settings, libellé d'accessibilité « Paramètres ») qui ouvre Settings. Le composant est placé dans l'en-tête de l'accueil (HomeScreen.tsx), de « Mes tickets » (MyTicketsScreen.tsx) et dans TabTitle.tsx, le titre des onglets Profil et Parrains. L'onglet Profil n'a plus de liste « Mon compte » : la roue est le seul accès aux réglages.

SettingsScreen.tsx, repris d'une maquette Figma, sert d'accueil des paramètres. Une carte jaune affiche un avatar avec les initiales, le prénom et le nom (ou « Citoyen d'EtherBay » s'ils sont vides) et l'email ; les initiales et le nom complet viennent de displayName.ts, qui retombe sur les initiales de l'email. Suivent cinq cartes SettingsLinkCard, dans cet ordre :

La maquette prévoyait une entrée Langue séparée : elle n'a pas été reprise, la langue se règle dans Affichage.

Les réglages d'affichage et de notifications sont enregistrés à chaque changement par usePreferenceSaver.ts, qui appelle PUT /user/preferences, remet l'ancienne valeur et affiche un message si l'envoi échoue. Quand l'interrupteur général est coupé, les catégories sont grisées et affichées désactivées, mais leurs valeurs enregistrées sont conservées.

La carte du centre d'aide ouvre l'adresse de EXPO_PUBLIC_HELP_CENTER_URL. Tant que la variable est vide, la carte affiche la pastille « Bientôt » et ne fait rien : le site du centre d'aide reste à créer.

Le bloc « Compte et appareils » de l'écran Sécurité (portefeuille intégré, déconnexion de tous les appareils) a été retiré. signOutEverywhere existe toujours dans useAuth, mais aucun écran ne l'appelle.

#Parcours principaux

flowchart LR
  ON["Onboarding"] --> SI["SignIn"]
  ON --> SU["SignUp"]
  SU -->|"code email"| VE["Verify2FA"]
  SI -->|"2FA active"| VE
  SI --> AC["Accueil"]
  VE --> AC
  AC -->|"âge NONE ou REJECTED"| VA["VerifyAge"]
  AC --> BT["BuyTicket"]
  AC --> GT["GiftTicket"]
  AC -->|"phase WAITING_ROOM ou DRAWING"| WR["WaitingRoom"]
  WR -->|"replace"| LD["LiveDraw"]
  AC --> SC["ScratchCard"]
  SC -->|"replace"| MC["MyCodes"]
  AC --> RC["RewardsCatalog"]
  RC --> RD["RewardDetail"]
  RD -->|"replace"| SC

L'échange d'une récompense remplace l'écran de détail par la carte à gratter, puis la carte par la liste des codes : le retour arrière ne repasse pas par une carte déjà grattée. De même, la salle d'attente est remplacée par l'écran du tirage dès que la phase devient DRAWING ou COMPLETED.

#Ce que la navigation ne fait pas

• Pas de liens profonds. app.json déclare désormais "scheme": "blocklucky", utilisé par le retour de la connexion Google (expo-web-browser), mais le NavigationContainer n'a pas de configuration linking. Un lien de parrainage /invite/<code> ouvert sur le téléphone ne mène pas à un écran ; le code doit être saisi à la main dans l'inscription.
• Pas de restauration de session. Au démarrage, isAuthenticated vaut toujours faux, même si un jeton est stocké (voir Authentification et stockage sécurisé).
• Pas de garde par statut d'âge. L'ouverture automatique de VerifyAge est une invitation : aucun écran n'est bloqué côté application, c'est le backend qui refuse les opérations.

Pour ajouter un écran, suivre Ajouter un écran mobile.