1. Contexte
• Entreprise: Argent Bank, néobanque en ligne.
• Équipe: Sébastien (front-end), cheffe de projet (Mila), CTO (Avery), backend déjà en place (Swagger fourni).
• Livrables de la phase 1: application React responsive, authentification, profil, gestion du pseudo, Redux pour l’état global, intégration green et composants réutilisables.
• Point de départ: HTML/CSS statiques pour Home, Sign-in, Profile.
2. Besoin
• Transformer des maquettes statiques en une application React dynamique et sécurisée.
• Intégrer le nouveau système d’authentification avec l’API existante.
• Garantir une expérience fluide, accessible et performante dès la première version.
3. Client
• Utilisateurs finaux d’Argent Bank souhaitant accéder à leur tableau de bord.
• Équipe produit (Mila) pour le suivi et la priorisation via GitHub Issues.
• CTO (Avery) pour le respect des standards techniques et de sécurité.
4 Objectifs
4.1 Fonctionnels
• Visiter la page d’accueil.
• Se connecter (avec gestion des erreurs).
• Se déconnecter.
• Accéder à la page Profil uniquement après connexion.
• Afficher les infos du profil; permettre la modification du pseudo.
4.2 Techniques
• Gérer l’état global avec Redux.
• Respecter les bonnes pratiques de green code et de réutilisabilité.
• Couvrir les flux critiques par des tests.
5. Contraintes / défis
• Temps: délais serrés.
• Techniques:
- API existante (contrat Swagger à respecter).
- Sécurité des tokens (pas de refresh si non prévu; éviter stockage risqué).
- Routage protégé et gestion d’erreurs (401/403).
• Design:
- Reprise exacte du style fourni, composants réutilisables.
- Accessibilité (navigation clavier, ARIA, focus).
• Green code:
- Images optimisées (poids/dimensions).
- Bundle léger, code splitting, limiter les dépendances.
6. Processus / méthodologie
6.1 Analyse
• Lecture de la doc Swagger et cartographie des endpoints nécessaires:
- Auth: POST /login (token JWT).
- Profil: GET/POST/PUT /user/profile (Bearer token) — selon le contrat du repo.
• Parcours utilisateurs: Home → Sign-in → Profil → Edit pseudo → Logout.
• Modèle de données minimal côté front: auth.token, user.profile {firstName, lastName, userName}.
6.2 Découpage en issues (GitHub)
• Setup projet + tooling.
• Intégration Home.
• Routage et pages.
• Auth (formulaire, erreurs, token, “Remember me”).
• Protected routes.
• Profil (fetch, affichage).
• Édition du pseudo (form, succès/erreurs).
• Accessibilité.
• Optimisations perf/green.
• Tests (unit/integration).
6.3 Architecture et logique
• Structure: cf github
• Routage: React Router 6 (Home “/”, Sign-in “/login”, Profile “/profile”).
• ProtectedRoute: redirige vers /login si pas de token.
6.4 Choix techniques (justification)
• React + Redux Toolkit: simplicité des slices, thunks pour appels API, future scalabilité (transactions).
• Persistance du token:
- Priorité: cookie httpOnly si backend le permet.
- Sinon: stockage en mémoire + sessionStorage; option “Remember me” → localStorage (avec avertissement sécurité interne et expiration).
• Appels API: Axios ou fetch wrapper centralisé, intercepteurs 401 → logout ou redirection login.
• Formulaires: contrôlés (React), validation minimaliste.
• Erreurs: messages explicites (ex: “Identifiants incorrects”), états de chargement, désactivation des boutons pendant les requêtes.
• Optimisations green:
- Code splitting par page (lazy + Suspense).
- Images: formats WebP/AVIF si possible, tailles responsives, <img loading="lazy">.
- Style: CSS existant réutilisé; pas de UI lib lourde; composants maison.
- Dépendances minimales, memoisation (React.memo, useMemo) seulement si nécessaire.
• Accessibilité:
- Labels explicites, aria-live pour erreurs.
- Gestion du focus après navigation et après erreur.
6.5 Flux principaux
• Login
- Saisie email/mot de passe → POST /login → succès: stocker token, rediriger /profile → échec: message d’erreur.
• Chargement du profil
- Au montage de /profile, si token → GET /user/profile → afficher données.
• Édition du pseudo
- Formulaire “Edit Username” → PUT /user/profile → succès: maj store + confirmation → échec: message + rollback si besoin.
• Logout
- Purge token + état user → redirection /.
6.6 Tests et qualité
• Unit tests: slices Redux (reducers), utilitaires.
• Integration tests: SignIn (erreurs, succès), ProtectedRoute, Profile (fetch et mise à jour pseudo).
• MSW (mock service worker) pour simuler l’API en tests.
• Lint/format: ESLint + Prettier; hooks rules; commit hooks (lint-staged).
7. Analyse
• Lecture de la doc Swagger et cartographie des endpoints nécessaires (auth et profil), définition des parcours critiques et du modèle d’état minimal côté front pour limiter la complexité tout en assurant la sécurité et la scalabilité future (transactions).
8. Choix techniques
• React + Redux Toolkit pour une gestion d’état prévisible et extensible.
• Persistance du token privilégiant httpOnly si possible; sinon mémoire + sessionStorage / localStorage avec “Remember me”.
• Wrapper réseau centralisé (Axios/fetch) avec intercepteurs 401, formulaires contrôlés et messages d’erreur explicites.
• Optimisations green (code splitting, images WebP/AVIF, lazy loading) et accessibilité (sémantique, aria-live, focus).
9. Logique de résolution
• Routage protégé, récupération du profil après connexion, édition du pseudo via PUT, puis mise à jour du store et feedback utilisateur; gestion systématique des erreurs et du logout en cas de 401.
10. Stack utilisée
• Front: React 18, React Router 6, Redux Toolkit.
• Réseau: Axios (ou Fetch avec wrapper).
• Build: Vite (démarrage rapide, bundle léger).
• Qualité: ESLint, Prettier, TypeScript (optionnel selon consignes du projet).
• Tests: Jest + React Testing Library, MSW; Cypress (optionnel).
• CI: GitHub Actions (lint + tests) — optionnel.
11. Résultat final
• Fonctionnalités livrées
- Pages Home, Sign-in, Profile fidèles aux maquettes.
- Authentification complète avec gestion d’erreurs.
- Routes protégées.
- Affichage du profil après login, édition du pseudo avec retour utilisateur.
- État global centralisé via Redux (auth + user).
• Performance et green code
- Code splitting par page, images optimisées, dépendances limitées.
- Chargement initial rapide; bundle de base contenu.
• Qualité et accessibilité
- Navigation clavier complète, focus visible, messages d’erreur accessibles.
- Tests couvrant les parcours critiques.
• Maintenabilité
- Architecture claire orientée “features”, composants réutilisables (boutons, inputs, cartes).
- API centralisée, slices isolés, logique testable.