FE: Events-Detail doppelte Fetches vermeiden und Guest-Person-Lookup optimieren #173

New issue

Closed

opened 2026-07-02 20:13:10 +02:00 by niboer · 0 comments

niboer commented

2026-07-02 20:13:10 +02:00

Owner

Beschreibung

Die Events-Detail-Seite (events/[eventId]/+page.server.ts) hat zwei Probleme: (1) Doppelte Fetches derselben Endpunkte in beiden Tab-Zweigen, (2) N+1 bei der Gaesteliste durch fehlende Personendaten.

Befund

Doppelte Fetches (frontend/src/routes/app/events/[eventId]/+page.server.ts):

Z. 55+120: GET /api/v1/events/{eventId}/roles wird im needsSelfData-Zweig (Z. 55, zur Rollen-Pruefung) UND im needsOrgData-Zweig (Z. 120) geladen
Z. 70+103: GET /api/v1/persons?archived=false wird im needsSelfData-Zweig (Z. 70, fuer Haushalts-Mitglieder) UND im needsOrgData-Zweig (Z. 103) geladen
Z. 111: GET /api/v1/groups wird ebenfalls nur im needsOrgData-Zweig geladen, obwohl der needsSelfData-Zweig die Gruppen-Mitglieder bereits kennt (Z. 66)
Insgesamt: Bis zu 6 statt 3 Calls pro Seitenladung bei aktivierten Tab-Zweigen

Guest-Person-Lookup (frontend/src/routes/app/events/[eventId]/+page.server.ts:94-105):

GET /api/v1/events/{eventId}/guests liefert nur personId, keine Personendaten
GET /api/v1/persons (alle Personen) wird gebraucht, um Namen zuzuordnen
Das ist ineffizient, da alle statt nur der relevanten Personen geladen werden

IST-Zustand

[needsSelfData active]
  → GET /events/{id}/guests/me
  → GET /events/{id}/roles                  (fuer compositeRole-Check)
  → GET /groups/{groupId}/members
  → GET /persons?archived=false             (fuer Haushalts-Mitglieder)

[needsOrgData active (gleiche Seite)]
  → GET /events/{id}/guests
  → GET /persons?archived=false             (DUPLIKAT!)
  → GET /groups                             (vorher nicht geladen)
  → GET /events/{id}/roles                  (DUPLIKAT!)
  → ggf. GET /templates

SOLL-Zustand

Deduplizierung:

persons, groups, roles werden EINMAL vor dem if (needsOrgData/isOrganizer)-Branching geladen
Beide Zweige referenzieren die gleichen Daten
Redundante Calls in Z. 55, 70, 103, 111, 120 entfallen

Guest-Person-Lookup:

GET /api/v1/events/{eventId}/guests?include=person liefert person-Daten inline
Kein separater GET /api/v1/persons mehr noetig

Abhaengigkeiten

blocked by #170 (guests?include=person) — Backend-Endpunkt fuer Gast-Liste mit Personendaten inline

Labels

component/frontend, prio/high, type/refactor

Meilenstein

MS-REST (#32)

### Beschreibung Die Events-Detail-Seite (`events/[eventId]/+page.server.ts`) hat zwei Probleme: (1) Doppelte Fetches derselben Endpunkte in beiden Tab-Zweigen, (2) N+1 bei der Gaesteliste durch fehlende Personendaten. ### Befund **Doppelte Fetches** (`frontend/src/routes/app/events/[eventId]/+page.server.ts`): - **Z. 55+120:** `GET /api/v1/events/{eventId}/roles` wird im `needsSelfData`-Zweig (Z. 55, zur Rollen-Pruefung) UND im `needsOrgData`-Zweig (Z. 120) geladen - **Z. 70+103:** `GET /api/v1/persons?archived=false` wird im `needsSelfData`-Zweig (Z. 70, fuer Haushalts-Mitglieder) UND im `needsOrgData`-Zweig (Z. 103) geladen - **Z. 111:** `GET /api/v1/groups` wird ebenfalls nur im `needsOrgData`-Zweig geladen, obwohl der `needsSelfData`-Zweig die Gruppen-Mitglieder bereits kennt (Z. 66) - **Insgesamt: Bis zu 6 statt 3 Calls pro Seitenladung bei aktivierten Tab-Zweigen** **Guest-Person-Lookup** (`frontend/src/routes/app/events/[eventId]/+page.server.ts:94-105`): - `GET /api/v1/events/{eventId}/guests` liefert nur `personId`, keine Personendaten - `GET /api/v1/persons` (alle Personen) wird gebraucht, um Namen zuzuordnen - Das ist ineffizient, da alle statt nur der relevanten Personen geladen werden ### IST-Zustand ```text [needsSelfData active] → GET /events/{id}/guests/me → GET /events/{id}/roles (fuer compositeRole-Check) → GET /groups/{groupId}/members → GET /persons?archived=false (fuer Haushalts-Mitglieder) [needsOrgData active (gleiche Seite)] → GET /events/{id}/guests → GET /persons?archived=false (DUPLIKAT!) → GET /groups (vorher nicht geladen) → GET /events/{id}/roles (DUPLIKAT!) → ggf. GET /templates ``` ### SOLL-Zustand **Deduplizierung:** - `persons`, `groups`, `roles` werden EINMAL vor dem `if (needsOrgData/isOrganizer)`-Branching geladen - Beide Zweige referenzieren die gleichen Daten - Redundante Calls in Z. 55, 70, 103, 111, 120 entfallen **Guest-Person-Lookup:** - `GET /api/v1/events/{eventId}/guests?include=person` liefert `person`-Daten inline - Kein separater `GET /api/v1/persons` mehr noetig ### Abhaengigkeiten - **blocked by #170** (`guests?include=person`) — Backend-Endpunkt fuer Gast-Liste mit Personendaten inline ### Labels component/frontend, prio/high, type/refactor ### Meilenstein MS-REST (#32)

niboer added this to the MS-REST: Restliche Aufgaben milestone

2026-07-02 20:13:10 +02:00

niboer added the

component/frontend

prio/high

type/refactor

labels

2026-07-02 20:13:10 +02:00

niboer referenced this issue from a commit

2026-07-02 21:01:26 +02:00

refactor: events-detail doppelte fetches vermieden und guest-person-lookup optimiert

niboer closed this issue