1. Contexte
• Agence: ArchiWebos (50 pers.). Projet: site portfolio d’une architecte d’intérieur.
• Équipe: vous (renfort front), Charlotte (PM/lead), équipe back (API + Swagger), UI/UX (Figma).
• Livrables: page portfolio dynamique, page de connexion, modale d’administration (ajout/suppression de travaux), intégration fidèle au Figma, code front livré et testé.
• Point de départ: Figma design, back-end (Node + Swagger), front statique d’origine, Kanban des tâches.
2. Besoin
• Alimenter la galerie depuis l’API, générer dynamiquement les filtres et permettre leur interaction côté client.
• Implémenter la page de login (authentification + stockage du token) et le mode administrateur (UI éditable, bouton “Modifier”, déconnexion).
• Construire une modale pour gérer les médias: affichage, suppression, ajout (formulaire avec upload image) et mise à jour du DOM sans rechargement.
3. Client
• Visiteurs: consultation des réalisations par catégories.
• Cliente (administratrice): gestion autonome de ses travaux via login et modale.
• Équipe ArchiWebos: code propre, maintenable, aligné au Kanban et conforme au Figma.
4 Objectifs
4.1 Fonctionnels
• Page “Travaux”: galerie alimentée par l’API, filtres par catégories (All + catégories réelles).
• Login: formulaire, redirection, gestion des erreurs (identifiants invalides).
• Mode Admin: bandeau/indicateurs d’édition, bouton “Modifier” qui ouvre la modale, bouton “Logout”.
• Modale: deux vues (Galerie photo avec suppression, Ajout photo avec preview), validation de formulaire, messages d’erreurs, mise à jour du DOM à chaud.
4.2 Techniques
• API REST (Swagger): GET/POST/DELETE avec token Bearer pour opérations protégées.
• Front: JavaScript vanilla (fetch, DOM), HTML sémantique, CSS/Figma existants respectés.
• Auth: stockage du token (sessionStorage recommandé), vérification de session au chargement, protection des actions (401/403).
• Accessibilité: structure sémantique, alt, focus management dans la modale, aria-\*; prise en charge clavier.
5. Contraintes / défis
• Fiabilité réseau/erreurs API (timeouts, 4xx/5xx) avec retours utilisateurs clairs.
• État global simple et synchronisé (galerie + modale) pour éviter les divergences DOM/données.
• Sécurité: token non exposé inutilement, nettoyage d’innerHTML si du contenu est injecté, validation stricte des fichiers (type/poids).
• Fidélité Figma: spacing, tailles, responsive de base, interactions prévues.
6. Processus / méthodologie
6.1 Analyse
• Lire le Kanban, parcourir le code existant, lancer le back, ouvrir Swagger pour lister endpoints (ex: GET /works, GET /categories, POST /login, POST /works [multipart], DELETE /works/{id}).
• Définir les composants front: Header/Auth, Gallery, Filters, AdminBanner, Modal (GalleryView + UploadView), API client, Store (état).
6.2 Découpage en issues (GitHub)
• Setup env: clonage, installation back, script dev front, variables de config API baseURL.
• Étape 1.1: fetch works → rendu galerie dynamique. Supprimer HTML statique.
• Étape 1.2: génération des filtres (catégories), gestion du filtrage client-side.
• Étape 2.1: intégration page login (Figma).
• Étape 2.2: POST /login, stockage token, redirection, affichage erreurs.
• Mode admin: affichage bandeau, bascule UI (masquer filtres si requis, afficher boutons “Modifier”, lien Logout).
• Étape 3.1: modale (ouverture/fermeture, focus trap, deux vues).
• Étape 3.2: suppression d’un travail (DELETE), mise à jour DOM (galerie + modale).
• Étape 3.3-3.4: upload (FormData, POST), validation, preview, ajout dynamique aux listes, reset du formulaire.
• Étape 4: QA: erreurs formulaires, a11y, responsive minimal, validations W3C, nettoyage.
6.3 Architecture et logique
• Arborescence front : cf github
• Flux:
- Au chargement index: fetch works (+ catégories ou dérivées de works), render gallery, build filters.
- Filtre: clic → applique predicate par categoryId, met à jour sélection visuelle.
- Login: POST /login → token en sessionStorage → redirection / index → init mode admin (bandeau + boutons).
- Modale:
- Galerie: liste des works (avec icône poubelle), suppression → DELETE → si 200/204: retirer l’item du store et du DOM (modale + galerie). Gestion 401/403/404.
- Ajout: formulaire (image, titre, catégorie). Avant envoi: validations (type MIME image/jpeg|png, taille max, titre non vide, catégorie choisie). FormData → POST /works (Authorization: Bearer token). Si succès: push dans store, render immédiat dans galerie + modale, reset form.
6.4 Choix techniques
• Vanilla JS: périmètre limité, perf et compréhension maximales, pas de dépendances.
• sessionStorage pour le token (persistance par session, réduit les risques par rapport à localStorage).
• Set pour dédupliquer catégories si aucune route dédiée n’est utilisée; sinon GET /categories pour source fiable.
• DOM update ciblée: éviter les rerenders complets (manipuler l’élément concerné), séparations en fonctions pures de rendu.
6.5 Flux principaux
• Navigation visiteur: voir toutes les œuvres → filtrer par catégories → consulter la grille mise à jour.
• Admin:
- Se connecter (login.html) → retour à l’accueil en mode édition (bandeau, boutons).
- Ouvrir la modale → supprimer un travail → l’élément disparaît immédiatement (sans reload).
- Ouvrir la modale → passer en vue “Ajout” → charger une image (preview) → saisir titre + catégorie → envoyer → nouvel élément apparaît dans la modale et la galerie → fermer.
6.6 Tests et qualité
• API: tester via Swagger/Postman (GET works, POST login, POST/DELETE works).
• Fonctionnels: filtrage correct, login erreurs (401), logout, modale (ouverture/fermeture multiples sans doublons DOM), suppression/ajout en direct.
• Accessibilité: alt images, ordre tab, focus visible, aria-modal/role="dialog", fermeture par Échap, focus trap dans la modale.
• Erreurs réseau: bannières/messages utilisateur (ex: “Impossible de charger les travaux”, “Suppression impossible”).
• Validation: HTML/CSS W3C, absence d’erreurs console, responsive minimal conforme au Figma.
7. Analyse
• La séparation API/Store/UI simplifie les mises à jour DOM et garantit la cohérence entre la galerie et la modale. En isolant la logique d’auth et en traitant finement les retours de l’API (statuts, messages), on obtient un front robuste et prévisible. La modale en instance unique évite les fuites et comportements inattendus.
8. Choix techniques
• fetch avec gestion centralisée des headers/erreurs; wrapper apiFetch qui jette des erreurs explicites.
• Prévalidation côté client des formulaires (titre, catégorie, image type/poids) pour UX; validation serveur reste source de vérité.
• Nettoyage DOM avant rerender (ex: container.innerHTML = '' puis append), ou update granulaire pour perf.
• Sécurité UX: échapper/contrôler les champs potentiellement injectés dans innerHTML; préférer textContent pour le titre.
9. Logique de résolution
• Démarrer par la lecture/essai de l’API → construire la galerie dynamique → ajouter filtres → intégrer login et token → activer le mode admin → modale (affichage) → suppression → upload → mise à jour dynamique → finitions UX/A11y/erreurs.
10. Stack utilisée
• Front: HTML5, CSS (styles existants), JavaScript ES6+ (modules).
• Back: Node/API fournie (Swagger pour doc/tests).
• Outils: VS Code, Live Server, Postman/Swagger, ESLint/Prettier, Web DevTools (network, a11y).
• Dépôt: GitHub, issues/Kanban, branches par feature, PR/reviews.
11. Résultat final
• Site portfolio dynamique: galerie alimentée par l’API, filtre par catégorie, login opérationnel, mode admin visible, modale complète (suppression + ajout avec preview), mises à jour sans rechargement.
• Qualité: UX claire, accessibilité respectée, erreurs gérées, code modulaire et maintenable, conforme au Figma et prêt pour soutenance.