FE: Consent-Dialog und Person-Detail von Waterfall-Requests befreien #172

New issue

Closed

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

niboer commented

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

Owner

Beschreibung

Der Consent-Dialog (consent-dialog.svelte) und die Person-Detail-Seite (persons/[personId]/+page.server.ts) machen client-seitige Waterfall-Requests, die durch Server-Datenversorgung eliminiert werden koennen.

Befund

Consent-Dialog (frontend/src/lib/components/consent-dialog.svelte:36-81):

1. GET /api/v1/persons/{id}/invitations (falls keine eventId gesetzt)
1. GET /api/v1/groups (alle Gruppen laden)
1. Pro Gruppe: GET /api/v1/groups/{id}/members (N Calls, sequentiell per for-of)
1. GET /api/v1/persons (alle Personen fuer Namensaufloesung)
Summe: N+3 client-seitige Calls, sequentiell, bei jedem Oeffnen des Dialogs

Person-Detail (frontend/src/routes/app/persons/[personId]/+page.server.ts:20-68):

1. GET /api/v1/persons/{personId} (Einzelperson)
1. GET /api/v1/groups (alle Gruppen)
1. Pro Gruppe: GET /api/v1/groups/{id}/members (N Calls)
1. GET /api/v1/persons (alle Personen fuer Namensaufloesung in Schleife Z. 61-64)
Summe: N+3 Server-Calls, nur um die Gruppenzugehoerigkeit einer Person zu ermitteln

IST-Zustand

[Consent-Dialog offen]
  → GET /api/v1/persons/{id}/invitations  (wenn keine eventId)
  → GET /api/v1/groups
  → GET /api/v1/groups/{id1}/members       (sequentiell)
  → GET /api/v1/groups/{id2}/members       (sequentiell)
  → ...
  → GET /api/v1/persons                    (fuer Namensaufloesung)

SOLL-Zustand

Consent-Dialog:

Daten werden von der aufrufenden Seite via Props/$page.data an den Dialog gereicht
Layout oder Dashboard laden die benoetigten Daten server-seitig und geben sie weiter
Der Dialog macht KEINE eigenen API-Calls mehr

Person-Detail:

GET /api/v1/persons/{personId}?include=group (1 Call statt N+3)
Backend liefert { ..., group: { groupId, name, members: [{personId, firstName, lastName}] } }
Kein manuelles Iterieren ueber alle Gruppen mehr

Abhaengigkeiten

blocked by #169 (groups?include=members) — Backend-Endpunkt fuer Gruppen-Daten mit Members inline
blocked by #171 (persons/{id}?include=group) — Backend-Endpunkt fuer Person inkl. Gruppen-Mitgliedschaft

Labels

component/frontend, prio/high, type/refactor

Meilenstein

MS-REST (#32)

### Beschreibung Der Consent-Dialog (`consent-dialog.svelte`) und die Person-Detail-Seite (`persons/[personId]/+page.server.ts`) machen client-seitige Waterfall-Requests, die durch Server-Datenversorgung eliminiert werden koennen. ### Befund **Consent-Dialog** (`frontend/src/lib/components/consent-dialog.svelte:36-81`): - 1. `GET /api/v1/persons/{id}/invitations` (falls keine eventId gesetzt) - 2. `GET /api/v1/groups` (alle Gruppen laden) - 3. Pro Gruppe: `GET /api/v1/groups/{id}/members` (N Calls, sequentiell per for-of) - 4. `GET /api/v1/persons` (alle Personen fuer Namensaufloesung) - **Summe: N+3 client-seitige Calls, sequentiell, bei jedem Oeffnen des Dialogs** **Person-Detail** (`frontend/src/routes/app/persons/[personId]/+page.server.ts:20-68`): - 1. `GET /api/v1/persons/{personId}` (Einzelperson) - 2. `GET /api/v1/groups` (alle Gruppen) - 3. Pro Gruppe: `GET /api/v1/groups/{id}/members` (N Calls) - 4. `GET /api/v1/persons` (alle Personen fuer Namensaufloesung in Schleife Z. 61-64) - **Summe: N+3 Server-Calls, nur um die Gruppenzugehoerigkeit einer Person zu ermitteln** ### IST-Zustand ```text [Consent-Dialog offen] → GET /api/v1/persons/{id}/invitations (wenn keine eventId) → GET /api/v1/groups → GET /api/v1/groups/{id1}/members (sequentiell) → GET /api/v1/groups/{id2}/members (sequentiell) → ... → GET /api/v1/persons (fuer Namensaufloesung) ``` ### SOLL-Zustand **Consent-Dialog:** - Daten werden von der aufrufenden Seite via Props/$page.data an den Dialog gereicht - Layout oder Dashboard laden die benoetigten Daten server-seitig und geben sie weiter - Der Dialog macht KEINE eigenen API-Calls mehr **Person-Detail:** - `GET /api/v1/persons/{personId}?include=group` (1 Call statt N+3) - Backend liefert `{ ..., group: { groupId, name, members: [{personId, firstName, lastName}] } }` - Kein manuelles Iterieren ueber alle Gruppen mehr ### Abhaengigkeiten - **blocked by #169** (`groups?include=members`) — Backend-Endpunkt fuer Gruppen-Daten mit Members inline - **blocked by #171** (`persons/{id}?include=group`) — Backend-Endpunkt fuer Person inkl. Gruppen-Mitgliedschaft ### 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:03 +02:00

niboer added the

component/frontend

prio/high

type/refactor

labels

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

niboer referenced this issue from a commit

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

feat: consent-dialog und person-detail von waterfall-requests befreit

niboer closed this issue