Planning — Agenda

Non contrôlé, sur le payload JSON-LD

Le composant tient les événements, la vue et la date. Navigue : la série récurrente suit, les événements datés non. Un événement à cheval sur plusieurs jours apparaît dans chacun, et les morceaux qui ne sont pas de vraies extrémités le disent.

showEmptyDays

Par défaut les jours vides disparaissent : un agenda liste ce qui a lieu. Activé, chaque jour de la fenêtre garde sa place — utile quand l'agenda sert de relevé plutôt que de liste.

Contrôlé, avec le journal des changements

L'application tient les événements et reçoit chaque changement. Les boutons ci-dessous appellent l'API du hook directement — exactement ce que font les gestes de la grille horaire, et ce que fera l'éditeur.

renderEvent

Quand la carte par défaut ne suffit pas, l'événement se rend entièrement à la main. La fiche normalisée arrive en premier argument, et `source` y porte l'objet d'origine intact — ici la salle et le @type maison.

La fiche — details

Consulter n'est pas modifier, et c'est le cas courant : un rendez-vous se regarde bien plus souvent qu'il ne se change. La fiche s'ouvre donc en lecture, et un bouton Modifier n'apparaît que là où les permissions l'accordent — la même coquille sert les deux, parce que deux composants partageraient le placement, l'en-tête et le pied, puis divergeraient au premier correctif. Ce qu'elle imprime vient de fields, où chaque descripteur porte la propriété qu'il lit : une propriété ajoutée côté serveur devient une ligne ici en une ligne, en lecture comme en écriture.

Modifier ouvre le formulaire dans la même coquille : le titre, les deux bornes, la journée entière, puis les champs déclarés. Rien n'est écrit avant Enregistrer — le brouillon ne touche pas l'événement, et l'abandonner ne coûte rien, ce qui est toute la différence entre un éditeur et un geste. Supprimer se confirme sur place, le bouton devient Confirmer : un modal dans un modal est une impasse. Et tracer une plage vide ouvre le même formulaire, déjà rempli de la plage — créer, c'est éditer un événement qui n'existe pas encore. Le lieu est un objet Place : un champ texte le réduirait à une chaîne, donc il est déclaré editable et servi par un select maison qui rend un vrai objet.

getEventPermissions répond à une seule question — ce que cet utilisateur peut faire de cet objet. Ici l'heure du conte est en lecture seule : sa fiche s'ouvre, mais elle ne se déplace pas et ne montre aucune poignée — les autres, si. Un même accesseur commande donc la fiche et les gestes. Attention : refuser la lecture ne masque rien — ce qui ne doit pas être vu ne doit pas être envoyé, et le tri d'autorité reste côté API.

Quatre réservations, quatre endroits différents où se trouve la date : dans reservationFor pour le concert, startTime/endTime pour la table, checkinTime/checkoutTime pour la chambre, et pickupTime seul pour la navette. L'adaptateur les trouve toutes les quatre sans lire un seul @type — c'est la liste ordonnée de paires de datePairs qui répond, et elle s'étend pour tes propres sous-types. Ici la fiche s'ouvre en feuille par le bas : c'est la même, avec un placement différent.

Ouvre la réservation du concert et clique Modifier : les dates sont là, mais verrouillées, avec la raison écrite. Elles n'appartiennent pas à la réservation, elles appartiennent au concert — les changer replanifierait la soirée pour tous les autres réservataires. La chambre et la table, qui portent leurs propres dates, s'éditent normalement. Ce n'est pas une limite, c'est ce que dit le vocabulaire ; et le refus tient en un seul prédicat, pour le jour où un cas particulier devra l'ouvrir.

Dans un téléphone

La même vue, sans une prop de différence. Elle s'empile parce que son conteneur est étroit, pas parce que la fenêtre l'est : l'agenda répond à sa propre largeur, ce qui est le seul critère juste — un panneau de 360 px sur un grand écran a exactement le même besoin qu'un téléphone.