diff --git a/CLAUDE.md b/CLAUDE.md index 717fd31..f7f2819 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -3205,11 +3205,35 @@ titres **intacts**, un article ajouté à un numéro existant par l'écran d'éd qui se recharge bien d'un numéro à l'autre. Aucun débordement horizontal à 320 px (`scrollWidth` = 320). -⚠️ **Défaut voisin constaté au passage, NON corrigé** : le bouton « Ajouter ce numéro » vit dans -`Revue.razor` alors que le champ « Numéro » vit dans `ChampsNumeroRevue`. Une frappe ne -re-rendant que le composant qui l'a traitée, le bouton **reste désactivé** tant que le parent ne -se redessine pas — seul `Entrée` (qui appelle `OnEntree`, donc le parent) enregistre le numéro. -À traiter. +### ⚠️ Un champ dans l'enfant, le bouton dans le parent : le bouton reste figé + +Constaté au passage, puis remonté en usage : « Ajouter ce numéro » restait **grisé** quel que +soit le numéro tapé, et ne se dégrisait qu'après un détour par « Modifier la revue » puis +« Enregistrer ». + +**Blazor ne redessine que le composant qui a traité l'événement.** Le champ « Numéro » vit dans +`ChampsNumeroRevue`, le bouton dans `Revue.razor` : une frappe re-rendait l'enfant, jamais le +parent, dont l'attribut `disabled` restait celui du dernier rendu — c'est-à-dire celui d'un +champ vide. Le détour « débloquait » parce qu'il redessinait le parent, pas parce qu'il validait +quoi que ce soit. `Entrée` marchait déjà, lui, puisqu'il passe par `OnEntree`, donc par le +parent. + +⚠️ **Le remède est une notification, pas un contrôle de saisie** : `OnChangement`, un +`EventCallback` que l'enfant invoque — invoquer un callback du parent le redessine, c'est +exactement ce qui manquait. + +⚠️ **Aucun champ ne se lie plus directement à `Saisie`** : tous passent par une propriété du +composant qui prévient. Y compris ceux dont aucun bouton ne dépend aujourd'hui — faire dépendre +la correction de « lequel commande quoi » la ferait oublier au premier champ ajouté. + +**Règle à retenir au-delà de ce cas** : un composant de saisie qui écrit dans un objet **prêté +par son parent** doit prévenir ce parent, sinon tout ce que le parent calcule à partir de cet +objet (bouton désactivé, compteur, message) reste figé sur l'état d'avant. Le symptôme est +trompeur — on cherche une validation fautive là où il n'y a qu'un rendu manquant. + +Vérifié en exécution, sur les **deux** formulaires (ajout et modification d'un numéro) : bouton +grisé à champ vide, dégrisé dès la première frappe, regrisé si l'on efface, et le clic — sans +`Entrée` — crée puis renomme bien le numéro. 617 tests au vert (618 avant : le test du découpage des unes n'a plus d'objet). diff --git a/MaBibli.Client/Composants/ChampsNumeroRevue.razor b/MaBibli.Client/Composants/ChampsNumeroRevue.razor index e09f49e..335be27 100644 --- a/MaBibli.Client/Composants/ChampsNumeroRevue.razor +++ b/MaBibli.Client/Composants/ChampsNumeroRevue.razor @@ -5,11 +5,17 @@ modification doivent proposer exactement les mêmes champs, sinon une couverture ou une une saisies à la création ne seraient plus modifiables ensuite — ce qui est précisément le cas d'usage (on ajoute un numéro le jour où on l'achète, on en recopie la une plus tard). + + ⚠️ Aucun champ ne se lie DIRECTEMENT à « Saisie » : chacun passe par une propriété qui + prévient le parent (OnChangement). Blazor ne redessine que le composant qui a traité + l'événement — une frappe ici ne re-rendait donc pas l'écran qui porte le bouton + « Ajouter ce numéro », et celui-ci restait grisé jusqu'à ce qu'autre chose redessine le + parent (enregistrer la revue, par exemple). Voir CLAUDE.md. *@