(S8) Mission 3: Développer la portion client de l'application en utilisant Supabase comme source de données

Votre mission

Pour cette troisième mission (en équipe), valant pour 40% de la note finale, vous aurez à développer le côté client de votre application à l'aide d'Angular comme cadriciel client et de Supabase comme source de données.

Pour une équipe de 2, vous n'avez qu'à implémenter la portion Discord.

Si, exceptionnellement (ex.: je vous ai permis de le faire), vous faites le travail individuellement, voir la section adaptation pour un travail individuel.

Contenu Supabase de référence

Comme base pour votre application, vous pouvez utiliser le contenu Supabase suivant: Base Supabase pour Discreddit

Spécifications

• Général

  • Authentification et Autorisation via le choix d'un pseudonyme et la restriction des accès aux routes si aucun pseudonyme n'a été choisi/enregistré (les utilisateurs avec mot de passe seront couverts dans la deuxième moitié de la session). Le tout doit utiliser le stockage local et permettre la connexion/déconnexion.
  • Utilisation de Supabase et de son API comme source de données
  • Tous les utilisateurs seront en quelque sorte considérés comme administrateurs (ils peuvent tous effectuer les mêmes tâches). La gestion des droits et permissions sera couverte dans la deuxième moitié de la session.
  • Les utilisateurs peuvent toutefois ne modifier que les messages ou commentaires dont ils sont l'auteur.
  • Mise à jour automatique (sans devoir recharger l'application) via polling des messages (Discord) ou des commentaires (Reddit)

• Discord

  • Gestion des serveurs (CRUD complet)

    • Nom
    • Description
    • Image
    • Timestamps (date de création/modification)

  • Gestion des canaux (CRUD complet)

    • Serveur associé
    • Nom
    • Description
    • Archivé
    • Image
    • Timestamps (date de création/modification)

  • Messages (chat) (CRUD complet)

    • Canal associé
    • Auteur (pseudonyme)
    • Contenu
    • Timestamps (date de création/modification)

  • Au moins un formulaire de création/modification doit se faire dans une fenêtre modale (popup)

  • Il doit obligatoirement être possible de basculer entre les canaux d'un serveur sans changer de "page" et ainsi ne pas perdre l'état de l'application. Voir la section Considérations d'architecture d'implémentation pour la portion Chat pour plus de détails. Par exemple:

    attention

    Il s'agit d'un exemple extrêmement simplifié permettant de montrer le comportement de navigation!

    

    Vous pouvez aussi adopter une approche similaire à Discord et tout montrer sur une seule page, mais assurez-vous de consulter la section Considérations d'architecture d'implémentation pour la portion Chat pour des trucs d'implémentation.

  • Les canaux étant archivés (propriété archived) doivent être affichés avec une couleur distinctive (ex.: grisés) ou séparés des canaux non archivés

  • Une option de filtre ou de recherche

  • Une fonctionnalité supplémentaire de votre choix (ex.: changement de thème/couleurs, un filtre supplémentaire de votre choix, etc.)

• Reddit

  • Gestion des communautés (CRUD complet)
    • Nom
    • Sujet
    • Image
    • NSFW
    • Timestamps (date de création/modification)
  • Gestion des publications (CRUD complet)
    • Communauté associée
    • Titre
    • Auteur (pseudonyme)
    • Contenu
    • Image
    • Timestamps (date de création/modification)
  • Commentaires (CRUD complet)
    • Publication
    • Auteur (pseudonyme)
    • Contenu
    • Timestamps (date de création/modification)
  • Une option de filtre ou de recherche
  • Une fonctionnalité supplémentaire de votre choix (ex.: changement de thème/couleurs, un filtre supplémentaire de votre choix, etc.)

Adaptations pour un travail individuel

Pour un travail individuel, vous devez faire le même travail qu'une équipe de 2 (Discord), mais avec les exigences réduites suivantes:

• 2 CRUD seulement: canaux et messages (assumez que vous êtes dans un serveur quelconque)
• Pas de fonctionnalité au choix

Modalités de remise

• Votre projet devra être remis sur un dépôt GitLab
• S.v.p. déposer sur Léa, pour votre équipe, un fichier .txt avec le lien vers votre repo GitLab (un coéquipier peut faire la remise pour l'équipe)
• Vous assurer de me donner les droits suffisants à votre repo (developer ou maintainer)
• Sur votre dépôt, il doit y avoir votre projet Angular complet
• Remis avant le 24 octobre 2025 23:59

Grille d'évaluation

Critère	Points
Implémentation des fonctionnalités requises et niveau de complétion	40
- Gestion des CRUD de base (3 ou 6 selon la taille de l'équipe)	20
- Filtre(s) ou recherche	5
- Support pour le téléversement et l'affichage des images	5
- Polling pour mise à jour des messages / commentaires	5
- Fonctionnalité(s) au choix	5
Utilisation de l'API REST Supabase et des services	15
- A (25) → L'API REST Supabase est très bien utilisée et la logique applicative est correctement déléguée à la couche services.
- B (20) → Dans l'ensemble, l'API REST Supabase est bien utilisée et la logique applicative est délégué à la couche services.
- C (15) → L'API REST Supabase est utilisée et la logique applicative est déléguée à la couche services, mais de façon inconstante OU l'implémentation est partiellement inadéquate.
- D (10) → L'API REST Supabase n'est pas ou très peu utilisée OU la logique applicative n'est pas ou très peu déléguée à la couche service.
- E (5) → L'API REST Supabase n'est pas utilisée et la logique applicative n'est pas correctement déléguée à la couche services.
Utilisation adéquate des composantes, gestion des erreurs, des états et des événements	15
- A (20) → Le concept de composants et la façon de communiquer entre eux est très bien utilisé, l'état de chargement est correctement communiqué et les erreurs sont très bien gérées.
- B (16) → Le concept de composants et la façon de communiquer entre eux est bien utilisé en général, l'état de chargement est communiqué dans la majeure partie des cas et les erreurs sont bien gérées.
- C (12) → Le concept de composants et la façon de communiquer entre eux pourrait être grandement améliorés OU l'état de chargement est peu communiqué et la gestion des erreurs peu présente.
- D (8) → Le concept de composants et la façon de communiquer entre eux n'est pas adéquat ET l'état de chargement et la gestion des erreurs sont peu présents.
- E (4) → Le concept de composants et la façon de communiquer entre eux n'est pas adéquat ET l'état de chargement et la gestion des erreurs sont absents.
Utilisation adéquate du routing	10
- A (10) → Les routes sont très bien définies, utilisent des chemins significatifs et la gestion des changements liés au changement d'URL est fonctionnelle et très bien implémenté.
- B (8) → Les routes sont généralement bien définies, utilisent des chemins significatifs et la gestion des changements liés au changement d'URL est fonctionnelle.
- C (6) → Les routes sont généralement définies, mais leur gestion pourrait être améliorée, tout comme la gestion des changements liés au changement d'URL.
- D (4) → Les routes sont peu ou incorrectement définies.
- E (2) → Les routes ne sont pas du tout utilisées correctement.
Gestion des accès aux routes et connexion/déconnexion	10
- A (10) → La connexion est très bien implémentée à l'aide d'un formulaire, le localstorage est très utilisé via un service ET les routes sont protégées à l'aide d'un guard.
- B (8) → La connexion est implémentée à l'aide d'un formulaire, le localstorage est correctement utilisé via un service ET les routes sont protégées à l'aide d'un guard.
- C (6) → La connexion est dans l'ensemble fonctionnelle, mais présente des lacunes dans son implémentation OU les routes ne sont pas protégées par un guard.
- D (4) → La connexion n'est pas fonctionnelle ET/OU les routes ne sont pas protégées par un guard.
- E (2) → La connexion n'est pas présente et les routes ne sont pas protégées par un guard
Documentation, bonnes pratiques et qualité générale	10
Total	100

Attentes et considérations d'architecture d'implémentation pour la portion Chat

Pour ce travail, il vous est demandé que la portion Discord (chat) de l'application permette obligatoirement de basculer entre les canaux d'un serveur sans changement de page/composant.

Plusieurs options s'offrent à vous pour structurer votre application afin de respecter cette contrainte.

Page individuelle par serveur et canaux/messages sur la même "page" (approche suggérée)

Vous pouvez simplifier l'architecture de l'application en demandant à l'utilisateur de faire une première sélection d'un serveur. Ensuite, sur la page d'un serveur, vous implémentez le comportement 100% dynamique.

L'architecture suivante vous aidera à obtenir ce comportement.

Cette approche permet de conserver un aspect dynamique à l'application, permet de répondre aux critères de l'énoncé et facilitera l'implémentation (plutôt que de gérer serveurs, canaux et messages "sur une même page").

Dans le contexte d'un travail d'équipe, il est aussi plus facile de vous séparer le travail ainsi. En effet, un coéquipier peut travailler sur la portion "serveurs", alors que l'autre sur la portion canaux/messages sans trop vous piler sur les pieds.

À éviter

Vous devez éviter l'approche suivante, soit que une page = une responsabilité. En effet, elle n'est pas adaptée à une application de chat et ne vous permettra pas de satisfaire les attentes quant à la gestion des composants et des événements.

À la Discord

Serveurs, canaux et messages sur la même page avec gestion du changement d'URL

Pour obtenir un comportement similaire à Discord, avec serveurs, canaux et messages sur la même page, tout en conservant le changement d'URL, vous devrez utiliser un deuxième router outlet et des routes enfants (children routes).

Cela vous donnera un comportement similaire à ceci. Remarquez bien que l'URL change dans la barre d'adresse, sans toutefois réinitialiser l'état:

L'expérience est fluide, en plus de garantir qu'on peut revenir à un canal ou un serveur spécifique en tapant l'adresse dans la barre de navigation. Mais l'implémentation est plus complexe.

En effet, vous aurez besoin d'un 2e Router Outlet pour conserver le comportement dynamique et le changement d'URL pour 2 niveaux (serveurs et canaux).

Serveurs, canaux et messages sur la même page, sans gestion de changement d'URL

Vous pouvez aussi faire une version intermédiaire, ressemblant à Discord, mais sans changement d'URL dans la barre de navigation. Cela est moins idéal, mais vous pourrez tout de même conserver un comportement similaire. Ne pas avoir à gérer les changements d'URL simplifiera le tout. Une architecture comme celle-ci est l'idéal dans ce cas.

À éviter

Vous voudrez éviter une architecture dans laquelle vous imbriquez les composants l'un dans l'autre. En effet, la communication entre composants se fait seulement à un niveau (parent->enfant). Si vous dépassez ce niveau de hiérarchie, cela devient très difficile à gérer et un peu "Spaghetti".

Évitez donc ceci!