BUG: EventsPage — dialog snapshot conditionné par @if (pattern orphelin, cf. fix c266f26) #38

Closed
opened 2026-08-10 21:37:40 +02:00 by nonobis · 1 comment
Owner

🎯 Contexte

Bug connu documenté dans le projet (fix c266f26, 08/2026) : ne jamais wrapper un MudDialog @bind-Visible dans un @if. Quand le @if passe à false, le composant est détruit au lieu de recevoir Visible=false, le dialog reste affiché par le provider mais orphelin, et plus aucun bouton ne répond. EventsPage contient encore ce pattern.

🔍 Observé

src/Heimdall.Web/Components/Pages/EventsPage.razor L66-79 :

@if (_showSnapshotEvent is not null)
{
    <MudDialog @bind-Visible="@_showSnapshot" Options="_dialogOptions">
        ...
    </MudDialog>
}

❌ Attendu

Le MudDialog doit être toujours rendu, la visibilité pilotée uniquement par @bind-Visible ; le contenu interne peut être conditionnel (_showSnapshotEvent is not null), pas le composant lui-même — alignement sur le pattern des autres pages corrigées (CamerasPage, SitesPage).

🧪 Reproduction

  1. Ouvrir /events, cliquer sur l'icône image d'un événement → dialog snapshot.
  2. Fermer par overlay/Échap, puis rouvrir un autre snapshot : le composant est remonté via @if → état fragile ; si _showSnapshotEvent est mis à null pendant que le dialog est visible, le dialog reste affiché mais orphelin.

💥 Impact

Dialog orphelin, boutons morts, tests bUnit en timeout (le MudDialogProvider ne rend pas le dialog inline comme attendu) — incohérence avec le fix c266f26.

🛠 Correctif

  1. Retirer le @if autour du MudDialog ; garder _showSnapshotEvent pour les données, rendu conditionnel dans le DialogContent.
  2. Ajouter un test bUnit RenderPage<EventsPage> : ouvrir → fermer (overlay) → rouvrir un autre snapshot, vérifier que le dialog se ferme/rouvre correctement (pas de timeout, pas d'orphelin).

📁 Fichiers concernés (estimés)

  • src/Heimdall.Web/Components/Pages/EventsPage.razor
  • tests/Heimdall.Web.Tests/ (tests EventsPage)
## 🎯 Contexte Bug connu documenté dans le projet (fix c266f26, 08/2026) : **ne jamais wrapper un `MudDialog @bind-Visible` dans un `@if`**. Quand le `@if` passe à false, le composant est détruit au lieu de recevoir `Visible=false`, le dialog reste affiché par le provider mais orphelin, et plus aucun bouton ne répond. `EventsPage` contient encore ce pattern. ## 🔍 Observé `src/Heimdall.Web/Components/Pages/EventsPage.razor` L66-79 : ```razor @if (_showSnapshotEvent is not null) { <MudDialog @bind-Visible="@_showSnapshot" Options="_dialogOptions"> ... </MudDialog> } ``` ## ❌ Attendu Le `MudDialog` doit être **toujours rendu**, la visibilité pilotée uniquement par `@bind-Visible` ; le contenu interne peut être conditionnel (`_showSnapshotEvent is not null`), pas le composant lui-même — alignement sur le pattern des autres pages corrigées (CamerasPage, SitesPage). ## 🧪 Reproduction 1. Ouvrir `/events`, cliquer sur l'icône image d'un événement → dialog snapshot. 2. Fermer par overlay/Échap, puis rouvrir un autre snapshot : le composant est remonté via `@if` → état fragile ; si `_showSnapshotEvent` est mis à `null` pendant que le dialog est visible, le dialog reste affiché mais orphelin. ## 💥 Impact Dialog orphelin, boutons morts, tests bUnit en timeout (le `MudDialogProvider` ne rend pas le dialog inline comme attendu) — incohérence avec le fix c266f26. ## 🛠 Correctif 1. Retirer le `@if` autour du `MudDialog` ; garder `_showSnapshotEvent` pour les données, rendu conditionnel **dans** le `DialogContent`. 2. Ajouter un test bUnit `RenderPage<EventsPage>` : ouvrir → fermer (overlay) → rouvrir un autre snapshot, vérifier que le dialog se ferme/rouvre correctement (pas de timeout, pas d'orphelin). ## 📁 Fichiers concernés (estimés) - `src/Heimdall.Web/Components/Pages/EventsPage.razor` - `tests/Heimdall.Web.Tests/` (tests EventsPage)
Author
Owner

Corrigé et poussé (commits e0482d3, 63f7375 — hook auto-commit). Tests bUnit + Application verts.

Corrigé et poussé (commits e0482d3, 63f7375 — hook auto-commit). Tests bUnit + Application verts.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
nonobis/Heimdall#38
No description provided.