Projet 2: Enrichissement de l'application et transformation en PWA.

Contexte et objectifs

La section Avis et alertes présente les avis émis par la Ville de Montréal pour communiquer à la population des renseignements ayant un impact sur la vie quotidienne (avis d'ébullition d'eau, travaux, fermetures, etc.).

Le projet 1 a permis de bâtir l'interface interactive avec React à partir de données fictives. Cette deuxième phase vise trois objectifs :

1. Brancher l'application sur les données réelles publiées par la Ville.
2. Enrichir les filtres (sélection multi-valeurs avec retour visuel).
3. Transformer l'application en PWA installable et utilisable hors connexion.

Compétences visées

• Consommer une API REST depuis une application React (fetch, états de chargement/erreur).
• Transformer un schéma de données externe en un modèle interne cohérent.
• Concevoir une UX de filtres multi-valeurs avec retour visuel.
• Configurer un manifest d'application web et des icônes multi-plateformes.
• Implémenter un service worker avec une stratégie de mise en cache documentée.
• Valider la qualité d'une PWA avec Lighthouse.

Mandat

À partir de votre projet 1, vous devez :

1. Remplacer les données fictives par celles de l'API de la Ville.
2. Gérer les états de chargement et d'erreur de l'application.
3. Enrichir les filtres : sélection multiple et zone de filtres actifs.
4. Transformer l'application en PWA installable et fonctionnant hors connexion.

Spécifications

• En-tête – idem que projet 1
• Recherche – idem que projet 1
• Filtres (enrichis) :
  • Pour arrondissement et sujet : plusieurs valeurs sélectionnables simultanément (combinaison « OU » à l'intérieur d'un filtre, « ET » entre filtres).
  • Pour date : deux champs <input type="date"> (début et fin, tous deux optionnels).
  • Les valeurs sélectionnées s'affichent dans une zone de filtres actifs, sous forme d'étiquettes (chips) permettant de les retirer individuellement.
  • Un bouton « Tout effacer » réinitialise l'ensemble des filtres.
• S'abonner aux alertes – idem que projet 1
• Liste des alertes – idem que projet 1 — le bouton « Charger plus » est recommandé.
• Page de détail – idem que projet 1 (URL dédiée partageable).
• Responsive design – idem que projet 1
• États de chargement et d'erreur :
  • Indicateur visuel (squelette, spinner, etc.) pendant les requêtes API.
  • Message clair si l'API est inaccessible ou retourne une erreur.
  • En mode hors-ligne, les données mises en cache restent affichées.

Données (API de la Ville)

Les données doivent provenir du portail de données ouvertes de la Ville. Deux ressources sont disponibles :

• JSON standard (à utiliser par défaut) : datastore_search
• GeoJSON (si vous souhaitez afficher une carte — bonus) : avis-alertes.geojson

Normalisation

Les champs de l'API ne correspondent pas exactement au modèle utilisé dans votre projet 1. Implémentez une fonction de mapping isolée dans un module dédié (p. ex. src/services/alertes.js) qui convertit la réponse brute de l'API vers votre modèle interne. Cette séparation vous permettra de substituer la source de données facilement au projet 3.

Fonctionnalités PWA

• Manifest (manifest.webmanifest) configuré avec :
  • name, short_name, description, start_url, display: "standalone", theme_color, background_color.
  • Icônes 192×192 et 512×512 minimum, avec une icône maskable (Android).
  • Une icône Apple Touch (180×180) pour iOS.
• Service worker obligatoire. Vous pouvez l'écrire à la main ou utiliser vite-plugin-pwa (Workbox).
• Stratégie de mise en cache documentée dans le README. Au minimum :
  • Assets statiques (JS, CSS, images, polices) → précachés au premier chargement.
  • Données de l'API → stratégie StaleWhileRevalidate recommandée.
• Mode hors-ligne :
  • L'application démarre sans réseau (shell applicatif en cache).
  • Les derniers avis téléchargés restent consultables.
  • La navigation entre l'accueil et la page de détail fonctionne.
  • Un indicateur visuel informe l'utilisateur qu'il est hors-ligne.
• Installabilité : l'application doit être installable sur Android (Chrome) et iOS (Safari → « Sur l'écran d'accueil »).
• Cible Lighthouse : score PWA ≥ 90 et Performance ≥ 80 en production.

Remise

• Dépôt GitHub public (ou privé avec enseignant collaborateur).
• README.md incluant :
  • Instructions d'installation et de démarrage.
  • Stratégie de mise en cache choisie et justification courte.
  • Captures d'écran ou valeurs des scores Lighthouse.
• Lien du dépôt remis sur Léa avant la date limite : dimanche 4 mai 23 h 59.
• Pénalité de 5 % par jour de retard jusqu'au 6 mai. Au-delà, note de 0.
• Évaluation orale en classe le mardi 6 mai (≈ 10 min par étudiant·e).

Évaluation

Ce projet compte pour 30 % de la note finale, réparti comme suit :

Critère	Pondération
Fonctionnalités PWA (installabilité, hors-ligne, service worker, cache)	25 %
Consommation de l'API et normalisation (incluant états de chargement/erreur)	15 %
Filtres enrichis (UX, filtres actifs, réinitialisation)	15 %
Décomposition en composants et usage approprié des hooks	15 %
Fidélité UI et responsive	10 %
Qualité du code et README	10 %
Maîtrise du code (évaluation orale)	10 %